Handling Ambiguous Environments (LCPS01E06)
Listen on all Podcast Platforms, like Spotify, Overcast, Apple Podcasts, iHeartRadio, Amazon Music.
Episode Summary
How do you lead your team through ambiguity?
As an engineering leader, one of your key responsibilities is to navigate and guide your team through the uncertainty that often comes with new projects and goals. You are to ensure your team has the information they need to do the work that needs to be done. What, then, if you’ve gone to great lengths to bring clarity to your team, only to realize you’ve reduced ambiguity so much that there is no engaging challenge, no room for creative problem-solving?
In this episode, we discuss our guest’s recent trouble with helping her team gain clarity.
Originally, Sarah thought she needed to bring clarity to take her forming and storming team to a new level. However, over the course of the conversation, we realize that Sarah has focused too much on clarity, and her team needs her support in a different way. She has to reconsider her own role to her team, how she provides value to them, and challenge some assumptions she's made about them.
By the end of this episode, you'll come away with actionable strategies for shifting your focus from constantly driving for clarity to helping your team embrace and thrive in ambiguous environments.
Chapters
00:00 Introduction
05:02 Managing and Leading in a High-Change Environment
10:38 Navigating Uncertainty and Ambiguity
15:30 The Challenge of Clarity and Adaptation
19:19 Thriving in Ambiguous Environments
21:14 Reflection and Gut Instinct in Decision-Making
27:29 The Consequences of Gut Instinct and Leadership Myths
29:18 Finding Certainty in Company Goals and Strategy
34:26 Embracing Ambiguity: Shifting Focus
38:39 The Chokehold of Excel
43:13 Leaving Space for Questions
45:42 Avoiding Being in the Way
51:31 The Value of Discovering and Learning
56:20 Adding Skills to the Skillset
01:00:37 Balancing Understanding and Action
01:07:18 Taking Being Stuck as a Signal
***
We want to hear from you! Email us with feedback, questions, or topic ideas; I can't promise we'll always respond, but I can promise we read every email! At pod@lenareinhard.com.
Full Episode Transcript
Sarah: Yeah, and I think that's the perfect metaphor because also, to add in this to the strings instruments metaphor - I've, when I, my brother is the one who taught me how to play guitar. And I remember, when he would teach me a chord, I was, it was like, this is the exact position that it should be in.
Yeah. And I was like, okay, this is it. And then I would see him. It's like, but you, you don't do it exactly like that. like you're. Yeah. You're a little bit, to, to the side and it's not right at the center of the tab. and so maybe even this metaphor allows for that, right? that there is guidance, but perfection is not the most important thing.
Right? Like there is, there is a little bit of room that if you move your, your fingers in the violin or in the guitar for a little bit, and they're not exactly in the center, like precisely placed, you still get a good sound as well.
Lena: I'm recording this episode not in my usual storage closet at home, but in a hotel room in a city where I'm facilitating a leadership offsite for a group of 10 senior leaders in a scale up tomorrow. And I'll shortly tell you why this offsite is a good setting to illustrate the topic I'm talking about with my guest today.
That said, this hotel room has a ton of carpet and I'm hoping my audio editor and you, most of all, will be satisfied with the audio quality. This is Leadership Confidential with Lena Reinhard. Real talk on more than two hard things in technology, finding community, and becoming the engineering leader you can be.
Today, how to find out what your team actually needs from you, and how to create value in a high ambiguity environment.
I'm a systems person. Systems of humans and technology have fascinated me my whole life. The interconnectedness and complexity of social dynamics, power dynamics, and constant evolution of organizations are incredibly fascinating to me.
Even more so when my mission is to not just get a sense of how they function, like the organization and the humans it's comprised of, but also how to help them change. This systems appreciation is one of the skills that helped me operate as a leader. But like with any skill, it also biases my view of it.
Being a systems person also means that I always need to be careful not to overlook things. As someone who appreciates seeing the big picture of a team and organization, I also know I need to be mindful of the small things, the details, and not overlook them. Because just because I'm good at the big picture doesn't mean that's always what a team needs.
And I need to keep that in mind. Like with this workshop that I'm running tomorrow. The team that I'm working with actually doesn't just need someone with a big picture. My role is also to help this group of leaders achieve some ambitious goals, like laying foundations for becoming more of a team and steer their organizations through big changes this year.
I have a really clear mandate there about how I help them achieve that. Well, I can tell you more about that later. Because first of all, I'm really excited to share my conversation with my guest today with you. Her and I make an experience that many of us have at some point. In our conversation together, we find out that what my guest thinks the team needs, the team that she's working with, isn't what they actually need.
And you get to listen in as we understand that. Which isn't a thing that happens on a lot of podcasts. I'm really thrilled to share this with you.
My guest is Sarah. Sarah is not her real name, but we'll call her that for this episode.
Sarah has extensive experience in leading teams through complex and evolving environments.
She has a background in technology and software development and has recently navigated a big career shift from a tech-centric role to a prominent position in a logistics company. Her journey is really unique and has given her first hand insight into the complexities of managing and stabilizing teams in high change environments, especially when clarity is elusive.
In this episode, Sarah and I talk about her experience leading through ambiguity and how she drives progress with her multidisciplinary team. In the first part of this episode, you'll hear the topic that Sarah initially came to me with. She wanted to talk about how to help her team get more clarity and go from forming or storming phase to the next level.
But over the course of our conversation, Sarah and I realized that clarity isn't actually the point of what her team needs right now. And that as part of this, she also really needs to adjust the way that she thinks about her own role, how she provides value to her team, and challenge some assumptions she's made about them.
In the second part then, we get to more concrete takeaways about how to help a team connect with the value of their work in an environment with high ambiguity. As always, after my conversation with my guest, I'll share with you some tips for finding out what your team actually needs from you, like this off site team I'm working with tomorrow, and how to create value in a highly ambiguous environment.
Here's real talk on more than two hard things with Sarah.
Lena: So, what I heard from you that you want to talk about is managing and leading a team in a high change environment with a lot of things going on at all times. And struggling with things like creating stability for the team and others. And I see you even have a notepad with you that is exceptionally professional.
So, tell me more about that.
Sarah: So I changed jobs not too long ago, right? And the area that I'm in right now is energy transition. And so I work at a big company that is trying to meet some goals for their decarbonization journey. And the way that I understood management, or even software development before, was quite straightforward.
I think, you have, a product that you want to sell to users and you build that product and hope that the users will like it and that they will buy it. You've got some feedback, right? And so the, literature about software development was quite simple. You do these fast iterations, you get some feedback, you change it, and you build new things.
And that was sort of the bubble that I was in when it comes to tech. And so I started my leadership journey in that bubble and switching jobs into, from basically a tech company, into a logistics company was very different. Because first, this company doesn't– doesn't sell the tech, it sells logistics.
And so technology is never the first priority as it has been in all of my previous jobs, right? The focus on tech is the main thing, is the priority. The software department is the one that has the most budget, the most clarity on their vision, et cetera. And so it's the first time that I am in a company where tech is not the focal point of what they're doing.
And so in this energy transition space that I'm working in now, the users are internal. The requirements are sometimes laws from different jurisdictions, right? It could be Europe. It could be the, there's like an ocean, legal space, a legal entity that, that handles that.
Lena: I’m terrified already.
Sarah: It is. It's terrifying. And so the amount of stakeholders that are so different from what I would consider a normal user is many, right? Like, there's legal people. There's people that sell the products. There's scientists that need to know about the fuels of the different vehicles that we use to do transportation.
And so I think, I haven't changed jobs many times, but this has been the most difficult onboarding that I have been through in my life. Because, again, logistics. It's huge. It's a miracle that anything gets anywhere, honestly. With the amount of things and events that need to happen, it's just, uh, we should truly appreciate when something gets delivered to your house, because there's a lot of moving pieces.
And so with this, with the little understanding that I had about energy transition, it became very clear, very fast that the idea that I had of things that were outside of tech being really defined was very wrong. When I would think about, “Okay, there is some, legal, the legal team. They must know what is it that they're looking for.” Or, this other team, that, that are– that feel a little bit more official than software. And you realize that's not always the case. And especially for this phase, that the laws are changing, the goals of everyone are changing, right? To be carbon neutral. And so it was very difficult for me to get an understanding.
And I have the expectation of myself as a manager, that you fill in a lot of the gaps in understanding, right? For the people that are joining your team. And so I started hiring and people had a lot of questions and it was, for the first time in a long time, that I was just blanking on most of them.
You know, like, “But why do we do this?” “I don't know.” “Are we sure that this is the correct way of calculating carbon emissions?” “I don't know.” And so getting the, I think the first part that was challenging was getting people comfortable with not knowing or even, starting with myself, because we were very much in analysis paralysis, right? Where we were like, no, we need someone to tell us that this is the right thing. And we were not getting it.
And so it was like, how can we do something, how can we do anything then? And so I think I was questioning a lot, and I still am, right? Like, even how much of this ambiguity is okay? Like, when does it become a red flag that we don't know enough? Because of course, we hired a lot of people that come from tech companies, where the users are maybe a little bit more, I don't want to say easy, but it's a little bit easier to get these requirements. When it's just about consuming a product.
And so this switch, or this almost yeah, what's the name of this? This tracker of ambiguity. When, at what point does it need to be that you say, okay, no, we have no idea what we're doing. We need to stop the tracks and, escalate this because I don't want to continue building something that I'm not sure what it is. And so I think that was the question that I was asking myself a lot when I first joined the team.
Lena: Wow, that does sound, like, really intense. How long have you been in this company now?
Sarah: Eight months.
Lena: And how long did it take for you to feel onboarded?
Sarah: Honestly, six months. Yeah, it was, at least. Like I even still feel sometimes that I'm just getting the hang of it. And, I think that, I thought I was good with ambiguity at my previous job.
Like when you got a new project, and, of course, I had context about all of the things that were happening already, because I was there for a long time. And so I used to think that I was good at picking something up without much information. But I think I didn't know what that was at all. I definitely had information.
And then – I had forgotten how exhausting it is to learn new things. It is— it takes so much energy to try and map things in your mind of the things that, that are involved in the domain.
And again, because a lot of the value that I've seen a manager bring is filling in the gaps of some people. Sometimes you need to at least feel, even if it's not true, that you do have a little bit more context than the rest of the team. And I think that I couldn't do that for a long time.
Lena: I feel like, I mean, honestly, just the environment that you're working in is, it's so fascinating. I have so many questions. But I also love how it really sounds like coming into this and you just described going from feeling quite good at handling ambiguity and then realizing, oh, damn. This is an entirely different ball game or we're not even playing ball games anymore. This is diving. And that it also made you question what your role is and what value you add to the team?
Sarah: Yes, very much because I also had to learn how to gain the trust of everyone again. I did find that it was relatively easy for me to gain trust when you know, what is it that you're talking about. When you have a confident voice telling you what the right way is to do things or what are the options to do something. You feel like someone is thinking about the big things and that makes me feel safe and good and confident that this worry that I have is in someone's mind.
And I couldn't do that. And also, like, the entire tech stack was new to me. So I knew that the first place where I wanted to place my focus was on, on bringing this context to the team. But I think like one of the questions that I have is how much to push for.
So I will tell you that I love working with products, right? I really like to be this connector between product and an engineering team. It makes me feel really good. I really like discussions, but it was just, it was so different to what I was used to and it is still so different to what I'm used to.
Because product, when it's not this thing that you want to sell, but it's something that, first, people need to use. You know, like it's not optional for people to use this tool and they need to go there. So the idea of building product is also different, right? Like the principles of building product change a little bit when you want to build a good product, but they also have to use it.
And so it's not a choice that any user is making. When you know, you're like, okay, yeah, this is the right, task manager for me. This is the one that I like. And so at the beginning, I felt that I was challenging product a lot without getting any answers of like, you know, why are we doing this? Who is the user? And at some point I got comfortable with the ambiguity of, “You know what? I like to do things and if I continue to ask these questions, I'm not going to do anything.”
And so we changed the narrative a little bit in engineering to be like, we're going to build something and we're going to learn something from it.
But it is—it feels like such an ask of trust from the engineering team, because the way that I visualize it for me is that we're in a forest full of fog and we don't know what is out there. And it could be that a tree is right in front of us and we can step on it, but we don't know, and we need to take that step to know if we need to take a step back and change directions, or if we're good to keep going. But it feels a little bit wrong for engineering to be doing that, at least in the sense of — we think a lot about, especially management, about resourcing, right? The work that you're throwing away. The waste that you're saving if you're building the right thing. And it just, it seems foreign to me to… and very much like, it seems very risky.
I think, yeah, it's risky because this check of, yes, I feel certain, or I feel like I've done the due diligence that this is not going to be wasted work? I get that less and less because it depends on this other factors that I, it's hard to get visibility on, right? Like, we can build something, we can build a tool today with a certain way of calculating carbon emissions. And it can be that this way gets deprecated tomorrow and then we need to change everything.
And to make the engineering team comfortable with that has been difficult.
Lena: I can imagine. It sounds like there's such a stark contrast between the ways that you were used to working where it was about – Basically, I get creating a lot of certainty early on, really understanding your user and the purpose for how they're like, how they're going to use the product and the cost that it's going to create and really basically getting it right from the beginning.
Yeah, very early on before you're starting to build. And now you're in a place where, like, I love the way you even described, how you early on, try to get all of those answers and increasingly realize that I'm just not going to get those answers because probably no one has them.
And then even, it sounds like you even got to a point where oh, this, it's not the point here. The point here isn't like what people are trying to do here is not to make everything or do everything correctly and the right way. But, there's probably a whole question about what are people trying to do? Um, that's definitely not it.
Sarah: And I wonder, like, just hearing you talk about it, I am thinking about the difference between a product organization and a research and development organization. Like how I was, I've always been in a, product organization where we build product. And I think that for this type of engineering where we treat it the same, right?
Or at least in, in the, from the engineering side, we think about it the same way. And it isn't. It's much riskier when you're doing research because you are learning, but you're learning through doing and I'm not in a, in an R&D space in, in the company that I'm in right now. But I think that is the way that we should be thinking about it.
Yeah, just comparing the two, yeah, the motivations are very different. And so even I wonder when we talk about clarity, right, and bringing clarity to the teams, how not only the role of your team, but the role of your organization and even the company can play a big part in that.
I usually don't think at that high level, right? Like I, I try to bring clarity to my team with the information that I have. If I'm in X department or if I'm in the Y department, I usually don't think about it that much, but I'm starting to realize that it is very important for the story that, that you want to tell, because it has to connect with the things that the team is doing.
Lena: And it sounds to me like there's also like the part that seems to me kind of connect to all of those questions that you posed is really how to handle an environment that's unpredictable in a lot of ways.
Sarah: Yeah.
Lena: And what does that mean for how you lead and how you work with people? And even, to your, like, should someone change the way they work to adapt to a team, you know, similar meta topic, just at a different level.
Sarah: Yes, because I think that there are people that really thrive in those environments. And it's usually people with backgrounds that made them confident in that. If I try and see the experience that makes you comfortable with ambiguity, I think startups go through, through that a lot.
And so people that come from working in startups are pretty good with that. And people that come from academia are actually really good with that.
Like to get a really big problem and then be like, “Okay, how can we turn this into smaller, simpler problems?” And I love that idea, but I think that for people that actually follow a more traditional path, like myself, right. Like I, I studied computer science. I… only in my Bachelor's. I went right into working and I've been working ever since. And I think this is very difficult for me and I see it in, in other people as well, that when you - I think we learn to attach our value to output, and to feel good about the output, you need to have a really clear idea of what is it that people expect from you.
And so letting go of this changes — it depends how difficult it is on many things, but I think that even the will to adapt to that, I've seen challenged. Like I don't like to work this way and I think that's okay. But I don't know if this is a problem of, I don't know who's, who needs to adapt, right?
Like, I, I don't know if it's okay, again, like, is, this team, is this project or product too ambiguous that we can't bring people that truly don't drive into this environment? Because that seems wrong to me.
But I also understand the other side of, “ Is this person too rigid in their way of working that they're not open to something new?” And I don't know, like, I haven't found a place where I feel comfortable leaning towards any, I'm just like, I see them both and I don't know how to get to an answer to that question.
Yeah, but that's one thing that has always made me uncomfortable when it comes to management that it, feels like it's so based on gut feeling. And I trust my gut. I, that, that is usually, how this conversations go when I'm concerned. I'm like, no, okay. I think this is a time where I need to raise that we need more direction here.
But it's also very worrying for me because I remember when I started in management and that I would hear this so often. So like you just know when it's time and you just know. And to me, it was like, it cannot be that is as esoteric as it sounds like. There is no way, but I understand a little bit more of the people that were advising me right at that point, because – and I don't know if it's a consequence of the way that we work, but I think that as a manager, you need to be really sensitive about signals that, that, you know, your team is throwing at you and that's okay.
But I think that there, I feel like there's a compromise or like, there's a give and take because – you forget to pick up the signals from yourself and then you can backtrack, you just know, you just feel that this is the time where you need to go and talk to the director of product.
And I want to know, when I'm mentoring someone that wants to get into management, and they asked me a question, I don't want to say, “You will know when it's time.” And I also, because it also makes me also lose trust in myself. What if one day I don't know? What if my gut is…
Lena: What if your gut is wrong?
Sarah: Yeah.
Lena: Yeah. I honestly, fully agree. I think, yes, we all, and that is, managers, leaders, but also just engineers —
people develop a quote, unquote, gut instinct over time or just instincts. And, those, of course, those exist and they're, the thing is, they're also not always correct.
They're usually, biases in the positive and negative sense, like shortcuts that we have based on our experiences in life and work and the way that we were brought up and the buttons that get pushed for us and the needs that we have. And those things can absolutely serve as good guidelines, but I also, they're still like, there's a lot of bias discourse is usually on the negative end and rightfully so.
They also mean that we make silly decisions or that we overlook people or are exclusive or just they're not always the perfect guide. And I think the point you made is really important that, they're also really, worst case, they're just perpetuating the bullshit myths about leadership.
Like, this idea was like, oh, you just know. Oh, yeah, that's not helpful.
Sarah: Yeah. Exactly. Yeah.
Lena: It was honestly, it just reminded me of like, I don't, I don't have children, but I have, folks who do in my friend's circle. And I know a lot of new parents were told, oh, you'll just know when your baby's not doing well. They're like, that's not – that doesn't feel safe. That is not a risk I want to take.
Sarah: And there's something like, there's something that I have been thinking about that I haven't been able to like complete that reflection.
But I remember when I, I went to a pottery class and it was a really frustrating experience for me the first time that I did it, because, again, usually, you know, when people come from what we like to think are exact sciences, but really are not in any way, you get a list of things that you need to do.
And you are able to say with certainty that something works or it doesn't work. This binary thinking that we hold so dear as something special. And I was asking like, but when do you know when the clay is ready? And the answer was, you just know. And I was like, this is not helpful for me.
Lena: (Laughs) That makes me so angry.
Sarah: And I, and I couldn't do it. And I think that there is something between art and how it has this blurry – yeah, this blur is on, on the edges of, you know, you, there is a lot of feeling to it. When you paint, when you declare that, which are the signals that your body is picking up on, but they're really subtle.
And so sometimes it's just really hard to explain. I think that it absolutely is the job of every manager to reflect on what is it that your body is feeling and why you're making those decisions. Because that to me, taking that time to reflect has – it makes career conversations much more interesting and just mentoring, and coaching also, just much more fruitful because that time off actually sharpens the edges of something that you think is like this, but you're not really sure how it is or why you made that decision. Or like trying to bring it back into, okay, no, now I know and taking all of the spices that you were mentioning into account when you're doing that, because one of the other questions that I have, it's like how to manage experts.
I will just, quickly talk about it. That one thing that I noticed when I was reflecting on this is that when I fall into this scenario, where I have a really senior engineer that has, is excited about some ideas, they are men and they are native English speakers.
And so I think that there is something to managers in general, just feeling like you are either understanding fully what is the, this project that they want to take on, or this, big refactor that they want to do, and forgetting that you're human and English is not my first language.
And so, maybe there are some words in there that I don't fully understand and being just, like, making sure that this alarm is a little bit on okay. Because I've now picked up on a pattern that I never thought had anything to do with the decisions that I was making.
And now I'm like, okay, this is the third time that this happens. And I see the pattern now and it's scary to, to realize almost a little embarrassing. Like, I feel bad that I didn't see it before and yeah, it's just awkward to look back at yourself and be like, “Okay. So that was part of it.”
Lena: Those realizations. Yeah, they take work.
Sarah: Yeah.
Lena: Kudos for getting there. And – but yeah, if, if we all rely on just yeah, gut instinct and the whole, it has such consequences. And that's another thing, honestly, that comes up so much in these conversations here is there's just such a blast radius of the stuff that we do and yeah, who gets promoted or who gets positive feedback on all the things that are needed to get there.
And, I do want to figure out with you, you know, what are things that are not ambiguous or things that are things that you can use for making these decisions and that you can also use to – this is you don't just have to make decisions. Like other people can too.
And the image I was thinking is, um, and your pottery class, prompted me to that is – so I play the violin, and I started as a, as a child already. I'm not good, but I do it. And, do you play a string instrument by any chance?
Sarah: I play a little bit of guitar, but very, very little.
Lena: Oh, but that's, that is actually perfect. What are these, on the guitar's neck, non-native English speaker. What are those things called? Do you know that? Are those the tabs?
Sarah: No, but I, yeah, the tabs. Yes. I know the word in Spanish, but…
Lena: In Spanish? Nice. What is it?
Sarah: Trastes.
Lena: Very good. See, we have an educational component right here. Um, and you notice, I do play probably four chords on the guitar, and that's all. But, my family members play, and so we always had guitars at home. But so with the guitar, you have those tabs, and you can feel where your hand is at, or at least somewhat directionally, right?
You can, yeah, feel the chord, or if you're doing… picking? I guess that's what it's called. Then, even then you have some guidance. Well, with violin, people may know that doesn't exist. It's just a very sleek, the neck of the instrument. You have 4 strings, and there's no guidance.
It's just, it's very sleek wood. Boom, done. But the thing is, of course, that works for me. At this point, you can, hand me a violin. If it's a full size violin, I will know just where to put my fingers. I can move, there are different transitions, positions. You can put the hands, so you can go really high, low, whatever.
But that took a really long time to learn. But at this point, I just know. And I wouldn't like, I could explain to you a few things with here are some things that need to be closer or so, but I, I would have to basically tell you, listen, like, I don't, I don't, I just know.
But when I was learning, of course, I didn't know, and I'm still, I would like to use this chance to apologize to my family for my first years of violin practice at home because it was terrible.
Um, but, so what my teacher did… She put, little Post-its with tape on the neck of the instrument. And put those in the first, like it's four positions for your, the four fingers that are actually on it. And then you have a bit of, first of all, of course, a bit of a tactile sense, and visual as well ‘cause of course, at that point you still look a lot, and it sounds terrible no matter if you look or don't.
But that's what I was thinking of. And then at some point I get kind of like training wheels with a bike at some point those get like you have fewer and you just have one left at some point. Your hand knows where to go and you can also of course your ear adjusts as well because you can then hear if the sound you're making is accurate or not, which also helps. But that's what I was thinking of, because it sounds like you're, that's the environment you're navigating.
Sarah: Yeah, and I think that's the perfect metaphor because also, to add in this to the strings instruments metaphor, I've, when I, my brother is the one who taught me how to play guitar. And I remember, when he would teach me a chord, I was, it was like, this is the exact position that it should be in.
Yeah. And I was like, okay, this is it. And then I would see him. It's like, but you, you don't do it exactly like that. like you're. Yeah. You're a little bit, to, to the side and it's not right at the center of the tab. And so maybe even this metaphor allows for that, right? That there is guidance, but perfection is not the most important thing.
Right? Like there is, there is a little bit of room that if you move your, your fingers in the violin or in the guitar for, a little bit, and they're not exactly in the center, like precisely placed, you still get a good sound as well, and so.
Lena: Let's stick with the guitar because there isn't much room with the violin.
Sarah: Oh, no?
Lena: No, I know with the guitar, you can actually, like, within the tabs, I think it's usually fine, but because the strings are much shorter, …
Sarah: Yeah. Okay.
Lena: It's really, it's very minimal and that's why, let's stick with the guitar metaphor.
Sarah: Okay, so it's perfection or nothing with the violin.
Lena: Or at least getting very close. Otherwise it's just, it just sounds terrible.
But so, you know, in the, I've heard from you, so many things that are really uncertain. Like the requirements change. It's even like, is this a product you're building or not? Who's using it? How are - What are the things you're putting in it? Are you doing the right things and whatnot?
Let's start at like, I want to find a couple of things that are certain in this. If you feel that's worth talking about, maybe it's something you've already spent a bunch of time on and didn't get far, then let's look at something else.
Sarah: No, I don't think I thought it this way like, uh, I think it was more like, I want to say brainwashed for lack of a better word. But just like…
Lena: (Laughs) Are you okay?
Sarah: (Laughs) But for myself, from me.
Lena: I see. Yeah.
Sarah: Just like, you know, a lot of, “This is okay, you don't have to know everything. We're gonna get through it.” Yes. And that is how I'm navigating through uncertainty sometimes.
Lena: That's fair. That's fair. So a couple of things that, may be certain, like the company and its strategy.
Sarah: Yeah, the goals are very certain, like company wide. It has very clear, ambitious goals of the company.
Lena: Are those for a year or even for longer time?
Sarah: For longer. It's 20 years, yeah.
Lena: Hot damn. That is long.
Sarah: Yeah. Yeah.
Lena: Nice. I, honestly, I've worked with a lot of people where the goals change every six weeks to three months. So honestly, you know, that is a huge certainty.
Sarah: Yeah, that's a big certainty. So there is certainty that, for us as a team, we need to exist. You know this…
Lena: Great. Job security.
Sarah: Yeah, exactly. Yeah.
Lena: Okay, so, as a team, do you have something like a team goal, strategy, mission, anything like that?
Sarah: We have a mission and we have a version of a roadmap that - it's a, yes, it's a version of a roadmap. But the goals are not super clear. I think it seems very project-based and the team asks a lot, like, what is the overarching goal of this? And it's very easy for us to point at this big goal of the company. But that's in 20 years. And so I, it's not enough.
But yeah, we have we have certainty around the projects, and I think it's exactly this gap that is causing the problem, right? Like,we know what we need to do today. We know what the company needs to do in 20 years. There's something missing in the middle.
Lena: It's like… next month. (Laughs)
Sarah: Next month, next three months. (Laughs)
Lena: I love that as a way to describe it. Also, like when you say you have some version of a roadmap, obviously, not going to ask for details, but, can you, cause it sounds you mentioned also there's projects I want to, know a little bit what that shape of that version of a roadmap is.
Sarah: So first is in PowerPoint, which is new to me as a roadmap tool.
Lena: (Laughs)
Sarah: But, but I do work in the corporate world now. But it's very, very high level, like we need to do this. And if you ask the question, what is it? There's no answer. So it's, it, you can tell that someone somewhere knows what we're doing. But it's not my media team. And so only when the time comes for us to pick those projects, it's okay, now we get to ask questions.
And so that's what I mean by a version of a roadmap. It's not…
Lena: Like a weird version of Christmas gifts or like birthday presents. Like when time is ripe.
Sarah: Yeah, yeah, exactly. Yes. So, yeah, that's what I mean by a version of a roadmap and it's not enough for, I mean, for me or for my engineers.
Lena: Where does that roadmap come from?
Sarah: The product team.
Lena: Are they, do you speak with them?
Sarah: Yeah, yeah, I speak with them.
Lena: Are you on a talking basis? (Laughs)
Sarah: (Laughs) We are, yes, we are on a talking basis. I like working with the product team, but our role is very much on, again, delivering this projects. And so I think the, this goal, goals in the middle are missing for everyone, also for the product team.
Lena: They don't really have the answers either. They're getting requirements from somewhere and then it's okay, we create the PowerPoint and now..
Sarah: Yes.
Lena: Engineering can execute. Okay. Okay. And how long are your projects usually? Like, is it, is it here's a week and then another week or is it more like several months or quarter?
Sarah: Yeah, probably in between that. So nothing has been as long as a quarter, but two months, a month and a half.
Lena: And your team mission, what is it about?
Sarah: So it's about providing tools for, to reach this company goal. So…
Lena: Yeah. Okay. So that also like that speaks to the, cause I was just like, that is helpful and also really not.
Sarah: Exactly. Yes. Yeah.
Lena: It's like, okay, well here's tools, but then the tools are sort of a six week project. And then there's the company goal is 20 years out.
Sarah: Yeah. Okay so, good that you understand why this doesn't feel right. Because in theory, I have everything that I need, right? I have projects, I have a vision. But it is, that is like a tool, what tool? For whom?
Lena: And when you've asked those questions, like for whom or why are we doing this sort of the classic product JP questions? What do you get?
Sarah: I get… to get to this goal, to get to this company goal, obviously. (Laughs)
Lena: Of course. Yeah, it's right there. (Laughs)
Sarah: And there's usually one person that is the user, which it's also weird. It was like, okay, who is this for? And instead of it being like, it was for this type of person. It's for this guy, this specific guy. And I'm like, if this, what if this guy leaves. Hello, he will never leave. And so, those types of answers are the ones that are good.
Lena: I love that though, because that is honestly, that is reminding me of like the worst user stories that I've ever seen, but that are also still so common. It's as a, whatever, rando guy X, um, but then there's also the name in it already. Ideally, there's like, as a, as a Lena Reinhard, I want be able to, provide an Excel sheet through by clicking like…
Sarah: You have no idea how many Excel sheets are involved in all of my projects. It's just the hardest tool to rip out of any user. Excel has a choke hold on everyone.
Lena: Nice. Yeah. That's, that's how Microsoft stays in power.
Sarah: Honestly, I have zero doubt now. It's just Excel. Excel is the main tool…
Lena: (Laughs) Yeah.
Sarah: …that is providing revenue for Microsoft. Yes.
Lena: That tracks. That's most corporations. Um, and, to the whole sort of, what are we doing here or how are we doing things? Like, what does, your manager – I don't know if you've spoken with them about, you know, huh, is this, this correct, or so. What does your manager think about it?
Sarah: So my manager is incredibly good with ambiguity. Like, uh, he has a software architect background and so he is very good at listening to a problem and going to solution mode right away. I think that where me and my peers support him is asking the rest of the questions, right? Like, um, because he will jump into solution mode right away.
So, anything is possible, no matter what the requirements are. But about building the right thing is the place where the engineering managers come in and ask questions. And so, for him, I think he's very used to. To not having all of the answers and not very used to having people dependent on those answers because, he's been working as an architect for a long time.
And so I think that only when we bring it up, it's a topic of conversation, but otherwise I, I think that he's very much in the mindset of, “Let's get something out there and then we can change it.” Which again, is fine, but it just, it lacks a certain stability for engineers.
Lena: Among other things, yeah. And you mentioned some certainty and stability a few times. Like it sounds like the engineers on your team would like more of that in some cases? Like how's…
Sarah: Yeah, definitely. And it's funny because at the beginning of the, when we first started as a team, there was a lot of feedback in the retros about, we don't know what we're doing. We are building something for no one. This type of questions about who is this for, et cetera, et cetera.
We put in the time to make sure that we had some answers to those questions, at least per project, so that we can, map it back to the engineers.
And we almost went the entire opposite of the spectrum.
So the feedback that I, that we got recently was that the project wasn't interesting enough. So, because we were so afraid of the ambiguity that we were passing to the engineers, we may have overdone it and being like, okay, these are all of the assumptions that we're going to make. This is the task that you need to, to bring to the team.
And so we went from this overwhelming, we can't do anything, now into this is almost too certain. That is boring. But it is a, that's the role that me and my peer took of trying to make it clear. And we've removed a good chunk of that, but it had the consequence of removing the interesting bits as well.
Lena: And that feedback that it's now almost like too clear and too boring, is that coming from the engineers on your team?
Sarah: Yes.
Lena: And how do you feel about that?
Sarah: I felt super bad. That was today. I was, I was like, wow, this is not what I was expecting. Because, when I think about the work that we're doing is again, so unclear, so ambiguous. And I did think for a second, we did a really good job then to bring clarity to the team. If the goal was to bring clarity and to be, to bring focus to an engineering team, we did amazing.
Because if the work is to the point that there are almost no questions, that's a, that's crazy for the amount of uncertainty that we're working with. But I also, it was just feedback that I didn't expect. And then now you're going to the question that I asked a couple of times, what context is too much context? In my mindset of “I'm trying to protect the engineers,” it seems like I'm also doing them a disservice.
Where, you know, I'm losing some engagement from them because I'm trying to protect them from this lack of certainty that was a problem. And so it also comes back to the flow of it. And this gut feeling that I think I missed this time.
I heard that my team needed certainty. I did something about it and I missed the time where it was, it's too much. Like you need to leave space for questions and for people to find out the answers themselves, because that's going to keep the work interesting. And I missed that. Until today.
Lena: Wow. and honestly, I don't know. That seems like such a huge point, even in itself, that, I honestly run into that a lot. And it's also something that I always need to be conscious of, like, all of us, either, you know, at some point, for example, get that feedback, “Hey, we want more clarity” and then just execute on that. And, either that becomes really the big idea that we attach to and, and it just, isn't necessarily automatically that we then continue validating or checking in, or even at some point, we have our own ideas about we think other people need.
And then just run towards that and forget that maybe their needs have changed or they actually need something else than we think. And so that's, you know. I mean, honestly, I'm glad you received that feedback and that people are so honest with you and open about what they need.
Sarah: Yeah I'm also glad about that. And because it does call for action again. It's okay. I get it and it's a balance that we will try to find. But of course, like why, hindsight is 20/20. And so I was like, of course, why did I think that the team of engineers would be scared to discover things? Like, why was I thinking that was work that I needed to do alone?
Yeah. And where it wasn't, it was that type of thing where you fall back sometimes as management being in this lonely, space where it's – okay, no, I need to bring clarity to my team. I need to go and find all of the answers and it doesn't have to be.
Lena: Honestly, that was like, I took a couple notes on the side, so it's like points that really stand out to me and that I want to bring back and that point you make – because you mentioned it even early on that question of what value am I bringing? As a manager, as a leader, and equating that, you viewed your own role as like, yeah, bringing clarity, having answers, filling gaps in knowledge, where other people don't have them.
And now it sounds like people are actually telling you, oh, yeah, we actually don't need that or not as much.
Sarah: Yeah. And it's terrifying for me as well, because I don't know if I'm happy to share that then I need to find the place where I'm needed. And the worst thing that, that you can be is in the way. And I don't want to be in the way.
Lena: Yeah, of course not. And also, I, it feels like your team has got the same question with like, what is the value we're providing? Because the value isn't right now in the, yeah, the value is like – to stick with my own example of that user story – for that one person.
Sarah: Yeah.
Lena: How is that measuring up towards that like long term 20 year goal?
Sarah: Today that was brought up. I was thinking also of, the story of the impact of the work, because we were working without a UX designer. And so we make a lot of decisions on our own and we depend highly on product to tell us about the people that are going to use it and any information that we need about them.
But, we don't know, because this is not like a customer product that you put out there and then you're able to see the downloads of the app or how many visits the product has. This needs more context of, when is someone coming into, into our product, what is the job that they're doing? And I think because we got used to working with this ambiguity and with putting stuff forward, even if we weren't so sure, to me, that was also a call again of “Who are we doing this for?” and not so much that the work is boring.
Because the work that they are doing is incredible. I think they just do not see how it's helping.
And so like mapping the impact to this as well, and it just it's also the focus that I can provide as a manager, but like, I focus very much on clarity for the past months. I need to focus on impact now. And I just wish that my gut told me sooner and not that I had to listen to this directly from the engineers.
Like that's the thing that I expect that the muscle or, brain mem— the memory just kicks in and it's like, “Okay, I think you're good with this. You need to move on to the next thing that, that your team needs help with.”
Lena: We've both had a night to think about it. I also, I'm sure you've had other things to think about as well, but I just wanted to ask, where are you at with all of it now?
Sarah: I actually met yesterday, like the meeting that I had to go to was with, a really good friend that I was her manager in my previous job. And we were talking about a few of the things that, that we discussed. And so I think, yeah, there, there were some light bulb moments yesterday, but there were also things that just - I feel like I should know more.
And just that feeling that you get sometimes of I should know a little bit more about this. I should pay more attention to it. But I think it's okay. I need to be patient with myself as well. So yeah, I had, I have been thinking about it a lot.
Lena: What were the light bulb moments you had yesterday?
Sarah: So I, I think that idea of focusing on discovery and the value that it has for an engineering team, like this different organizations, of being in the product organization and being an innovation organization, how different those can be. I think the realization of some of the bad things about my management style came up a lot and I could see it in, in my conversation with her as well.
That I think either I'm projecting or something else is going on about wanting this sort of protection from a manager that I think I take too far. I could hear it yesterday that we were talking about it, how, it went from bringing clarity and trying to protect the team from being overwhelmed that went into this other end of the range of it being too clear and not enough space for interesting discovery.
And I saw it in one of the - she was talking about where people are at in my previous job - and how some people really thrive from when you have a really supportive manager, and then the manager leaves, that you're able to see the potential that some people had, right. Because now there's a space to be covered.
And I wish that I had seen that when I was their manager. Like I, I definitely thought I was doing the right thing. I thought that I was embracing their, the qualities of the things that gave them energy. But there's something that feels a little bit, you know, disappointed in my gut of, even though this person is telling me that, they're happy and fulfilled and they like the rhythm of how they're working, that I want to be better at catching when I'm being too protective. That I'm actually being at like doing a disservice to the people on my team.
Because I think that I am very good at, or that I've had some success in seeing potential in, people, but I think especially when it's this type of expert that we talked about yesterday, of this really senior engineer that wants to do this different projects. And that's the type of person that I'm still learning how to manage best because I think what I've seen is that the style of management that I have, of course, doesn't work for everyone, but I need to learn to adapt to this type of profile as well.
Lena: it sounds like there's, I don't know, realization in there. And, that's honestly, what I was thinking about a lot since what's the value that I bring as a manager? And what's the value that, again, we bring as a team and how do I make that happen?
And to me, it sounds like, again, previously it used to be like being the person that drives clarity and getting like as much clarity as you can to the team and then delivering against that.
Whereas it sounds now, the value that you bring collectively as a team, and where you can support them is really in holding the ambiguity together, yet still getting clarity where you can, where it's possible.
But then, the value, it seems to me, it's really much more in the lessons you're learning.
I was often thinking of the growth engineering teams that I ran for a while, where the mission is very explicitly about, we're going to do a lot of throwaway work, but we're going to keep it short. We're going to keep the waste limited by just having very small experiments.
Our value is not in the product we're building, because there isn't necessarily a product. The value that we are delivering to the business is lessons learned. Experiments run, metrics that we're gathering, things that we learn about our users, their behaviors, their needs from that. And, but that is such a very different way, because I know so many engineers also get attached to it working on a product or find it really interesting to work for a certain type of user or so.
And with those teams, what was really striking to me always, is that the value is in the learning and in growing. And in being able to also say, okay, this didn't work. So, we're going to that away and not getting too attached to things.
Sarah: Yeah, and I think that is something that I don't know how to express yet as a value. Like also hearing you talk about it, absolutely. And even that gives me a sense of freedom, right? Because we have been attached so much to trying to find what the metric was to feel successful. And I think that even changing that conversation into “it’s lessons” is figuring out where the processes are missing because this is something new. It’s figuring out ownership of many things. That, if I changed my mind for a second and thinking that is success for my team, I feel really confident that we're doing it, but we haven't talked it.
And because yeah, we had been too close to the normal product development where we really focused on users. And again, it's people that don't really have a choice whether they get to use this tool or not. And so yeah, I think that's, something that I definitely will bring up to the way that we talk about impact because it is impactful work. It's just a little bit different.
Lena: They're quite different. And it sounds like there is basically, yes, one approach of working so far. You've tried it. Collectively, hasn't worked great. And now you've also been realizing together that, yeah, we just need a different approach.
Sarah: Yeah. And I think about what we were talking about yesterday as well, that, this idea of getting the team to feel comfortable with the changes that are going to come in. Even if we start talking about it as, “This as our job and our value is to discover all of these things.” I feel like the compromises that sometimes we need to make, because, data is not present, or this is the only thing that we have, et cetera. It just feels more comfortable, right?
Right, because our job is not to deliver, at least our job right now is not to deliver the perfect engineering system. It's to deliver the tools that highlight the gaps in the company.
Yeah. And that makes so much sense. And I'm excited to talk about it with my manager and the product team, because I think it would also help the product team to talk about a roadmap and the successes that, that we have when it's not mapped to a product delivery that has vague metrics around it.
I'm writing a note for myself, so I can bring this back to my team. But yeah. Yes.
Lena: Wow. What does that mean for, for you and your own role?
Sarah: It feels good. And you know what, like I remember when I was trying to change jobs, that I was looking, at some positions that were internal tools. And because I had been working on a customer product for a long time, there was a bit of friction whenever I thought about internal tools.
But I remember thinking how challenging it would be. And that I, that my experience wouldn't necessarily map to that. And so, it was something that I was, just avoiding or like taking the other way. And now that I'm in it, thinking about it this way, it feels like adding a skill to my skillset of, okay, there will be situations where talking about the impact of stuff, and your team needs it right to be engaged with the product, and to be engaged with their work and to feel motivated.
So are you sure that is the correct way or that there's not this other way of thinking about it, where the value that you're bringing is not like usage of an application, but is the discovery of other things in these lessons learned. So I feel like that enables me to think about other roles as well.
Like just, having that experience and this switch. And when I talk about it to my team, like I, I will see how it goes. But if it's helpful, it does feel like, ah, okay, I think I could do more internal tooling then because I would know how to talk about it.
Lena: To just expand on what you said, because I thought that was really great. There's also just, you can use different approaches. You can try different things. I mean, even if, you share this with your team and they all say, Oh, we don't, we hate that. That doesn't resonate with us. That's weird.
Honestly, it doesn't matter. I also don't necessarily think it's going to happen, but it doesn't matter. Because then you can talk about well, what are the things that would be motivating for you or that you're missing right now? How can we create them together?
So, I would even take that one step further to these are just different options of solving problems, but I also of course, we all have our innate ways of doing things or the ways that we've learned to handle certain situations. And, then, you know we move, to instincts and just doing things the way that we do them. Because, and we at some point, we probably can't even explain why anymore. But, yeah, there are different ways of looking at this. And then also, yeah, you don't have to be the person who figures all of it out. That's the other big part that stood out to me and how you just talked about it.
You can bring your team in and work with them.
Sarah: Yeah, and it feels also like unlocking this. Because to me, I felt that I was failing because I was not able to do it the way that I know how to do it. And it feels okay, now that I know that there's no one way of doing it, then maybe, there are just other ways that I need to try and see how it works.
So yeah, so it doesn't feel too, or as hard on myself than as it was before.Because it was very binary, right? The way that I was thinking about passing context and impact of our work to the team. And so I felt that there was one way of doing it and I was not making it work, and it was because of me and my skills that I couldn't pass that message in a, in an efficient way. And now it's opening up to, okay, I have other stuff to try. I haven't failed yet.
Lena: And if you do fail, you can recover.
Sarah: Yes.
Lena: Thank you so much for your time and for, all your openness and the extra time today.
Sarah: Thank you so much to you, Lena. I am always happy to chat with you. Always.
Lena: This is the first episode of this podcast where I kind of have two takeaway sections.
I'll first want to summarize a little bit some of the brilliant points that Sarah came up with when we talked about how to help her team deal with the high ambiguity. The second part I want to spend a bit more time on though is the big question that to me – really everything that Sarah shared, which is, sometimes our idea of what a team needs needs to be reassessed. And I'll share a couple thoughts on how to do that in practice, illustrated by the conversation Sarah and I had.
So let's start with the first part. A couple of concrete things for helping a team deal with ambiguity based on what Sarah shared. Like, first of all, shift focus with your team from driving to more clarity to just handling and embracing the ambiguity you're dealing with.
Embrace that the value that your team is providing isn't necessarily in exact features provided or in building things exactly to a user's needs. The value can also be in discovering, in learning lessons, in experimenting, and in learning. Those learnings in themselves can really be valuable. But in order to embrace that, teams need to reframe the way that they're having impact and success. Focusing much more on growth and those lessons learned instead of exact things delivered.
As part of that, also embrace failure. Create a space where people can actually talk about things that are going well or things that aren't. And an opportunity to grow in your new approaches. I'm honestly expecting that as Sarah's team is learning to embrace the ambiguity that they're dealing with, they will deal with some difficulties. And that's okay.
Now as I mentioned, there's the second part of this conversation. I learned so much from what Sarah shared and I thought it was really valuable and I'm so grateful that she walked us through this. Because to me it illustrates really how many times we need to reflect on what our teams actually need versus the assumptions that we make about what they need.
Many times, or actually most times in my experience, our job as leaders is to take four and a half steps. First of all, we assess what's going on. Then we diagnose and hypothesize. Step three is we identify levers for change. And step four is to take action and repeat.
That's fairly true in a lot of situations. I want to share a little bit based on Sarah's example. First of all, we assessed the situation and gathered some data. In this case, some of the data was Sarah's team doesn't really understand who they're building for and what their work is serving.
They're missing a purpose.
The environment they're in is the second part we looked at. It's a high-change environment. There isn't a lot of certainty or predictability around and that likely won't change a lot. Then the third bit is Sarah's boss. They think that things are kind of working okay. And then we looked at what's been working versus what hasn't been working for Sarah and her team.
Sarah's been pushing for more clarity that hasn't been really leading to anything. But what has been working well are the Excel files. All of this was really interesting to me. And that was also, in case you noticed it, an important point where we started reflecting on the assumptions that were going into this.
What are you looking at? What are you considering? Or what are you maybe not considering as you're looking into a situation like this one? The second step was we started diagnosing a little bit. That usually just means hypothesizing. In practice, I always recommend writing the hypotheses down, and then you can validate them with your teammates and your boss.
Sarah and I started our conversation with the hypotheses. This team needs more clarity and structure. They need a better roadmap. And Sarah's job is to figure out how to bring clarity to forming and storming team. What we landed on though, at the end was essentially the premise. This team still needs structure and clarity, but this clarity is likely not going to be in the form of roadmaps or user archetypes.
But in helping the team make sense of the operating mode that their company is in and make sense of the environment first. That is a very different kind of clarity.
By the way, that also, that kind of diagnosis and hypotheses, that doesn't mean the team needs to just accept things the way they are, but at least initially helping them shift the way that they interpret what's going on can have a huge impact on how the team feels and how they think about what they can change.
So, after the assessment and the diagnosis and hypotheses, step 3 is identifying levers for change. We didn't get into this in a lot of detail with Sarah, but one big part is the re-contextualization, essentially thinking very differently about the environment the team is in. Like acknowledging it is a high ambiguity environment. That's probably not going to change a ton. That can also help them rethink how they think about their work and then where they create value.
Now that you've identified some levers for change, the next step is to take action, like actually have those conversations that Sarah talked about wanting to have with her team. And then continuing to validate this.
I've been doing the exact same thing as I've been preparing for this offsite that I'm running this week. I ran a longer diagnosis. I got a first briefing from the group leader, in this case, a C-level executive with the goal for the session and the team. Then I spoke with everyone on this team and asked them a set of questions to understand how they think, what they value, how they operate as individuals and as a group, and also find some points of tension and conflict.
When I'm lucky, like with this group, people are super open with me. That makes my job as a facilitator a lot easier. Based on that, I form some hypotheses. Like in this case, for example, they're a team where everyone just joined the company recently. So likely they don't have strong relationships. They're still figuring out how to get things done for their own departments.
And they haven't figured out an operation model for their group. They may also come from different backgrounds, and since they're distributed across the globe, they may also likely have different cultures, communication styles, and operating modes. To me, those kind of hypotheses don't all have to be validated, but they form a first assumption of how this team works, and then also start informing my role in the way that I approach them as a group, as well as in the kind of tools and sessions that I run with them during our workshop.
Next up, again, I validated those hypotheses. I spoke with the C-level leader, I shared some information back to the team, and I gave them preparation materials. The next bit, the finding levers for change, and then also actually taking action, is what I'm going to do tomorrow in my session with them. And that's honestly always a bit of a bet, but that's the important part.
I can form some diagnoses. I can form some hypotheses, but I can't actually fully assess this. And that's my second big takeaway that I want to share with you for how to rethink your role as a leader. Don't get too hung up on trying to understand everything in detail. Because ultimately, you need to balance how much you want to understand what's going on with also actually being able to do something about it.
Because in an organization that's constantly changing, even the most perfectly accurate snapshot will just be a snapshot and not be accurate for very long because things just change too quickly.
Another point that my conversation with Sarah really highlighted to me is how important it is for us to know our own glasses. We talked a bit about instincts and I think it's always important to both listen to them, but also to challenge them.
There's this wonderful idiom that if you have a hammer, everything is a nail. And I mentioned at the beginning of this episode how I am a systems person and that's just how I look at things. We all have these kinds of glasses on, this kind of way in which we view the world. We all have a hammer or whatever the tool of your choice is.
I have this inclination towards systems. I'm also a structure person. In my early startup years, that often meant that chaos felt really wrong to me and like a problem to be solved. You may have heard of that kind of tendency. It's called, yes, exactly, a bias. Now, I will say many startups and scale ups that I work with these days often still have a level of chaos that is probably getting in their way a bit.
But some of this chaos can also be productive and helpful. And being able to discern those has been really important to me. So understand a bit what your default modes are, how you operate, how you view the world, and how that impacts the judgment calls that you make. And lastly, I also really appreciate that Sarah shared with me feeling stuck.
She felt stuck on how to help her team get to more clarity. Even though she's an experienced manager, she just couldn't figure it out. And I found this a lot in both my own journey as well as with the people I'm working with. Getting stuck is often a really good signal that you may be off, like you may be off in your diagnosis and the hypotheses you've formed.
If you feel stuck, it can often be worth taking a couple steps back and looking again at the data you're looking at. Like the conversations you've had with people, the perspectives that you're taking in, the way that you're interpreting that data. Take being stuck as a signal. Sometimes it also just means you need someone who can help you out a little bit.
But signals are really important guidance.
Thank you for being part of this episode and join me again next time on Leadership Confidential when we'll get real with two formidable leaders.
I'll talk with one about business impact in engineering and I also have a great conversation about having a micromanager.
This podcast is still new and we would love your feedback. Email us at pod@LenaReinhard.com. We can't respond to each email, but I promise we'll read it. And we'd like to hear from you.
Leadership Confidential was created, produced and presented by me, Lena Reinhard. Our guest's voice was digitally modified.
Theme, original composition, and mixing by Esteban Del Pino.
Production assistance, guest support, and social media by Sly Stark.
Thank you for listening. I'll hear you next time.
