Menu
.png)
Managers aren't the only people who act as leaders on a team. In fact, the role of a great manager is to enable others to shine and become leaders themselves. When team members have more space to lead their own work, that also has the benefit of freeing up managers to focus on even more high-level work.
Of course, enabling others to become leaders is easier said than done. To learn how to do this, we were lucky enough to hear from Laura Tacho (previously VP of Engineering at Aula Education and Nova Credit). Laura believes that leadership isn't about being an expert; it's about enabling others. She's done that effectively at several companies, and now coaches engineering leaders around the world to do the same themselves. You can watch the talk and find key takeaways below! The transcript is also at the end of this article.
Laura Tacho is an engineering coach who works with leaders to help teams shine. Before that, Laura led engineering and product development teams at companies like CloudBees, Aula Education, and Nova Credit.
She’s on a mission to equip engineering leaders with the confidence and skills they need to build high-performing software teams. Her teams consistently ship high-quality code sprint after sprint and outperform their competition. Outside of work, Laura enjoys grilling for friends in her backyard, climbing, skiing, and being up in the mountains with her husband and young daughter.
You can find her @rhein_wein on Twitter and learn more about her coaching programs at lauratacho.com
Powerful questions that open up discussions to empower your team
1-on-1 questions to learn about what the people on your team need
Trust quotient to help build trust on your team
We’re a group of engineering leaders who want to grow and learn together. This community is for engineering managers, heads / VPs / directors of engineering, and CTOs who want to learn with peers and care about people.
To support this community, we organize knowledge-sharing & networking events on a range of topics, mostly focused on the people side of leadership. We aim to make the tech industry more welcoming by creating a diverse and equitable community of peers and role models.
All attendees, speakers, volunteers, and organizers at any of our meetups are required to follow our Code of Conduct. Organizers will enforce this code throughout the meetup.
If you'd like to join, you can register your interest here.
[00:53] Lauren Peate: Let's go ahead and jump into it, because we want to save plenty of time to hear from Laura.
So I'm super excited to welcome Laura for this discussion. I got to meet her recently, and was really impressed by two things in particular that really stood out. One, she is clearly a very high integrity, high ethics person. It is very evident that she holds herself to a high bar and and does the same for people around her — so I always really appreciate and value that. And then the second thing is how much she's thinking about people and, and the care that she shows for people.
So for both of those reasons, I think she's going to be a great person to talk to us about how to empower your engineering team. In addition to that, she also brings a wealth of experience. She was an engineering leader at CloudBees, Aula Education and Nova Credit — and so she's seen companies and engineering teams through acquisition and also as they're scaling. Now she's an engineering leadership coach, and so she's also working with lots of different teams on these very same topics.
She's coming to us today from Austria, where she loves climbing, skiing and exploring the mountains, and then grilling for friends in her backyard. So with that, I'll go ahead and pass it to you, Laura. Thank you, Laura. Over to you.
[02:11] Laura Tacho: Thank you Lauren for that lovely introduction! I'm so glad to be here with everybody. We'll roll today without slides, because I think this is an interesting topic that just works better when we're all talking to each other.
So like Lauren said, I’ve been a VP of engineering at a few companies. Now I've been an engineering leadership for close to a decade. It's really hard to distill all of that experience down into 15 minutes in talking about empowered engineering teams. But I'm going to try to do it for you today. You can find me at lauratacho.com and on Twitter, so I'd love to connect with you there. I also have a course on developer productivity and performance that is very focused on the human side of things and treating engineers like human beings, and not just like data points on a screen. If you're interested in that, check it out.
I am in Austria... but I grew up in the United States. So I think also adding that complexity of different cultures, different languages has definitely influenced my leadership style and I lead a lot of distributed teams that are international and it's really complex. With that, let's just get into empowerment. And I wanted to start with actually a bit of a group activity because I think this is — when we talk about empowerment — the part that is missing from the conversation. So what I'm asking of all of you is to take 30 seconds to think about your definition of empowerment, what is empowerment and write it in the chat and share it with everyone.
I just want to see, you know, what you all think about empowerment so that we can tailor the conversation to it. So 30 seconds, I'll start a timer. Just put your definition, empowerment into the chat and then we'll go from there.
So if you're nervous about, you know, being one of the first ones, I'll put mine in there. I see lots of great answers here.
[05:17] Laura Tacho: [reading definitions from chat]: ‘Giving the space to be autonomous’, ‘giving people everything they need to achieve something' — I like that definition a lot. ‘People feel like they are free to suggest their own ideas’; ‘Building trust, people are uplifted’. ‘Everyone should be able to give their own opinion’; ‘Allowing people to make their own choices': these are all really fantastic definitions.
We're kind of getting the angle of psychological safety and empowerment. I think those two are quite related.
The interesting thing though about these definitions is that there's no two people in this room that have the same definition of empowerment…and I think this is the part that most leaders just miss.
When you are having a conversation about empowerment to your team, they also have a different definition of empowerment. Because if you ask this question to your team, they're gonna give you something totally, totally different. And in fact, the space between manager definitions of empowerment or manager definitions of productivity and performance or whatever it is, the space between those definitions and what your team thinks is often way, way, way bigger than we think it is.
So in this group, all of our definitions are pretty aligned. Even if we use different words. But when you check in with your team, they're gonna have a different definition. And that is step zero of having this conversation about what it means to empower your team. Because if you are not aligned on a definition, it becomes nearly impossible to move forward.
[06:47] Laura Tacho: My own definition of empowerment was a little off the cuff actually, but I think it is all about giving teams the space, but also the information that they need to be self-directed and be successful. What empowerment is not, is a lack of accountability or a lack of standards. And that often gets put together.
So as a leader, we might say, ‘Well, I wanna empower my team. So I'm gonna…. sit back a little bit and I'm just going to let them do their thing. And maybe they make a mistake, but it's all part of learning. And I think that attitude is really commendable. I think that the desire to step back to remove yourself from the conversation and to create space for the people on your team is, is coming from a really good place. But if we frame that action with the definition of what empowerment is — which is giving people what they need to be successful — you're kind of in a way, setting your team up… I wouldn't say to fail, because that's quite a strong word… but you know, you're not supporting them in their success the best way that you could be.
And if there's one thing to walk away from just this very brief few moments that I've been been sharing with you so far is have that conversation about what empowerment means, because if your team thinks empowerment means ‘I get to decide what to work on, I get to decide how to work on it, I get to set the schedule, I get to do everything’ and your definition of empowerment is ‘hey, we've got these business goals that we've got to meet, I'm going to suggest something. and I want you to feel free to share your opinion’…. those definitions just aren't going to mix. And you're going to end up with a team that feels disempowered, even when the actions that you are taking are ones that you think is empowerment.
[08:48] Laura Tacho: I want to share with you also a little bit about micromanagement here in empowerment, because now that I'm an engineering coach and I'm working with dozens and dozens of organizations at any given time — I'm working with Pfizer, I've worked with AWS, Apple, GitHub…all the way down to, you know, the smallest startup that is in super stealth mode that no one's heard of. It's interesting to see how it's just the same kind of the same five problems that pop up regardless of how big your company is or how small your company is. And one thing that when we talk about empowerment is and what empowerment is not — often, the answer to that question is micromanagement.
And I think that everyone in this room is probably deathly terrified of being a micromanager. It is like the, you know, it's just like the thing that we're most worried about. I want to share with you what I call the micromanagement spiral, which is a cycle that we get caught in as leaders. When we talk and when we're trying to avoid micromanagement and trying to empower our teams, what we can end up doing inadvertently is becoming the micromanager that we are so afraid of becoming, and I'll show you how this happens.
So I'm going to say that Lauren is my team member, and I need to delegate something to Lauren. So I'm going to say to Lauren ‘Hey Lauren, we need to finish this project. And I'd like you to figure out how the project gets finished. And, um, you know, can you tell me when you think it's gonna be done?’ I say these things because I want Lauren to have the space to figure out her timeline. I want her to figure out how it's gonna get done. I want to, you know, give her all the opportunity to be self-directed. But in doing that, what I'm not doing is sharing ‘Hey, this needs to be done by the end of the quarter because the VP really thinks that it's important. And also… the senior VP and marketing has eyes on this project because they've lost trust in our team that we haven't done it. And also I'm kind of expecting that you do it a certain way because three months ago or three years ago, we tried doing it and it didn't work'. So I'm really expecting you to find that knowledge.
And then when Lauren comes back to me and says ‘Okay — we're working on other stuff, we're gonna have this done at the end of Q4’ and ends up proposing a solution that is not the one that I expected. I end up having to go back to her and say, ‘Okay, well, I don't think this is going work. Let's go back to this. Or, you know, the VP is really concerned that this project is off track. We need to start having a standup, or we need to start putting an update so that the VPs can have visibility’
[11:25] Laura Tacho: Those are exactly the things I wanted to avoid but because I didn't give her enough context…because I was trying to empower her, I actually put myself in a spiral. Bring myself around to being a micromanager. And this is — I think — the hardest thing about being a leader… you need to find that line between directive and supportive and exactly how much space that you open up to your team.
There is, I think, a kindness and there is empowerment in being clear with expectations. I think there's a quote from Brene Brown that says like clarity is kindness… or whatever it is. I've actually never read any of her books… not that I have anything against her, I just haven't found the time!
But I think that clarity is kindness is so essential when you talk about empowerment because your teams cannot be successful without the clarity from you and without the information that they need to be successful. Teams do not want full carte blanche to just do whatever they want with no accountability. I think especially as engineering leaders, we feel like if we are too prescriptive, if we're too directive…we're going to lose our team. They're going to become upset with us. They're going to be mad at us because we're telling them what to do. We're holding them to standards that they don't agree with and they're just gonna quit. And then it's gonna take us six months to find another engineer.
The opposite is actually quite true. If you let everything slide, people think... well, this team has no standards. I am not, you know, I'm not gonna be able to do my best work here, so I'm gonna peace out and go find somewhere else to work. So there's this like really complex landscape around you when you're talking about empowerment… which is not micromanagement. But trying to be empowering can lead to micromanagement.
First of all, you need to make sure that your definition aligns with that of your team, because if they're expecting freedom to make their own choices, and you're just giving them freedom to share their opinion….you're going to end up down a dead end and with some dissatisfied people. Then also, you know, making sure that you are setting expectations and you still have high standards is really important in empowerment. That's what I wanted to share with you to kick this conversation off and kind of get you all thinking.
Thank you all for playing along and participating. I know that some of you has have sent questions in, so I will hand over to Lauren to get that Q&A sorted
[13:53] Lauren Peate: Amazing. Thank you. Thank you. So… LOTS of head nodding throughout that… so I can tell that that was really resonating. So I'm gonna kick it off. This is a question that Callum shared, and I'm gonna kind of weave it in with a question I had as well. Which is this tension you were talking about of giving people space to learn… which can sometimes mean the space to make some mistakes… because that is how we learn things often as humans. So how do we both give people the space for them to learn and make mistakes while still having the guardrails in place or, you know, making sure that they're still supported in getting the context? And, and also making sure that we're not making, you know, putting them in a situation where they're going to look bad or the company's going look bad?
[14:46] Laura Tacho: I'm going to answer this question with an example, not from engineering but actually about parenting and children on a playground that happened yesterday. I was up in the mountains with my husband and my daughter, and we were waiting for our gondola to take us up the mountain. And there's a little playground there and there was a rope, you know, like one of those rope ladders. Actually playgrounds in Germany and Austria are…they are built with risk…let me put it that way. They're not safe to fall off of.
So this little girl who must have been maybe five or six was up on this rope ladder, which is probably just as tall as I am. And she was about in the middle and I could see her parents looking at her.She's kind of like, all right, I'll see where this is going. And the dad asked her this question — basically, do you feel safe? Do you feel comfortable and confident with what you're doing right now? And then the girl said, ‘No, no, no — I want help. I want help. Please come and help me’. And she asked for the help and then she got the help from her parents.
So her parents could have seen that and been like, ‘Oh my God, what are you doing? Get down from there. I'm gonna come and help you!’….but they didn't. They gave her the space. Determined whether or not she was feeling comfortable. They gave her opportunity to say, I do need help now and then she took it.
So if we look at our teams, it is all about providing that constraint and that safe space for people. You can observe and let them go down a path. And if you see that the path is becoming unproductive or not fruitful, you can ask the question of like: Hey, how are you thinking about delivering this on time, given that you had this many setbacks? How can I support you? When can I expect to see an update from you on this?
These open-end ended questions are reinforcing boundaries. It's reinforcing what they need to do and reinforcing the standards you have, but without jumping and, you know, bringing the child down from the rope ladder… so that they can learn to test their boundaries and still have a safe space to make mistakes without getting completely derailed.
[17:00] Lauren Peate: That's great. I have a follow up on that which actually ties into the next question I was going to ask, which is around how do we kick these conversations off with our direct reports?
And that relates to question that Anna had had — what you were just talking about — what are good questions to ask about whether we're providing the right balance of support and empowerment? And so that's one, if you have anything to add on that, and then second, I want to go back to that earlier point around how empowerment is different to different people…and so I'd also love to hear how you kick off that conversation with your director reports.
How you structure it and the types of questions you like to ask there too.
[18:00] Laura Tacho: I actually have a resource, it's like a private security through obscurity resource on this, my list of powerful questions, and these are questions that I use and I advise my coaching clients to use in one-on-ones. We as engineers, we're quite logical. We ask questions in search of a specific answer…or sometimes we know the answer and we're just trying to get them and start a conversation. That technique can be quite detrimental to giving our direct reports and our teams, the space that they need to be self-directed and be empowered. These powerful questions are questions that are intended to open up conversation and really, really, truly give the space for your team to share.
Thinking back to that playground example, a closed question might have been, do you need me to come get you down? So in that question, the action of I'm going to come and get you down from that rope ladder was already in the question. So that outcome is already in the question, but an open question might be: Do you need help from me?
Which she might say is 'Yeah, please come and get me down' or 'No, I just want you to watch and make sure that I'm safe'. But if we ask the question, should I come and get you down? And all she wants you to do is watch to make sure that she's safe, you close off the conversation, and you're not letting the other person bring you what they truly need. And we do that as managers all the time. We think that we're gonna skip a few steps in the conversation by maybe suggesting the two things that might be most common, like, ‘Oh, are we late on this because we did a bad job estimating? Or because we didn't get the resources we needed from design on time?’
Well…maybe it's a third thing, completely different, and you're just not leaving space in the conversation, or if you're having a conversation about accountability and you say: ‘Why didn't you share with a marketing team that you were releasing this UI change before it went out?’
That's an assumption that that person didn't share and that's why marketing didn't know, but actually they might have shared three times and marketing just ignored them. But if we have these really closed questions, we just don't get that answer. So my answer to both of the questions Lauren is to use powerful questions — it's a really good technique. Specifically about empowerment, there are some around ending the conversation and establishing next steps. I find those really good for empowering conversations or delegation conversations. 'When do you want to check in about this? What resources do you need in order to make this successful? What's the first thing that you're going to do?'
These questions are really open, really letting that person be self-directed, but setting super clear boundaries. Like, hey, I am expecting an update about this. I'm expecting you to get to work. I want to know your plan, but doing in a way that doesn't feel like micromanaging.
[21:11] Lauren Peate: Love that. Such an amazing resource. Thank you. Thank you for sharing that. We've got time for a couple more questions — so last call of folks in the group. Have anything you want to add in?
One that came through earlier from Nadja was around if you see a difference in with engaging engineers as a group. Is there something that works differently for engineers compared to other types of humans that you've worked with?
[21:41] Laura Tacho: I really love this question because I have a bit of a… I wouldn't call it an unpopular take on this… but I think that the perspective that engineers are just weird, or really different or that we can't just treat them the way we would treat normal humans is… first of all, damaging to engineers as a population, because we're all just regular humans. But also I think very damaging to your business.
For the longest time, I mean, we've been in a bubble. I think we're seeing tech, the tech market just like cool down a little bit but it's still quite hot where we know engineers have choice. And a lot of times that choice in their employment leads us to think, well, we need to kind of bend the rules for them or cater to everything that they want because we can't hold them to the same standards that we would, you know, someone in marketing or sales, for fear that they're going to leave.
And I think this is damaging in a couple ways. First of all, I expect a lot from teams that I work with and if you want to expect a lot as well, you know, it starts with your attitude and your perception of the people that you work with. So you might really value your engineers and no doubt I do as well with the teams I work with. I really value their expertise, but I also expect a lot from them. And I know that they're incredibly smart people that are capable of communicating clearly, thinking through problems, handling edge cases, all these things that I do get questions a lot of: is it reasonable for me to expect that an engineer is going to write a summary of product functionality to share with a product manager or with a sales team?
Absolutely. If they're building it, they should be able to explain how it works in language that other people can understand. I think that is just a very, you know, fundamental professional expectation. So I guess my short answer would be: every person has preferences, whether they're an engineer or not.
I like to ask questions in one-on-ones about things like: How do you like to receive praise? How do you like to receive critical feedback? How do you like to have bad news shared with you? Good news shared with you. These things can help you understand people's preferences. You can't cater to them all the time.
But I wouldn't necessarily single out engineers as a population and try to treat them differently, even if I'm afraid that they're going to quit. Because chances are, if you bend the rules or lower your standards for them, they're going to think that this is not a team that they wanna be a part of because they can't do their best work here because you don't have great standards — so, it's a bit of a hard cycle to break. But that's my take on that question. Great question.
[24:31] Lauren Peate: Awesome. Great. Love those examples. So I'm going to roll together some of these last questions here and really focus on autonomy. I'm going to weave together a few around autonomy as an input. So teams who say: Hey, I need autonomy to feel empowered, or to start doing XYZ versus do people need to earn that autonomy — so work their way up to more and more of it. And then related to that, another question around cultural difference or across country, different expectations around the level of autonomy that people think they should be getting.
[25:25] Laura Tacho: I think the autonomy question is different for different levels of engineers. So, obviously junior engineers, early career engineers are going to need more guidance and it's your job to provide that guidance. But that guidance doesn't have to come from you. It can come from other members of your team. And I think looking at those, you know, mid-to-late career or mid-level senior staff, principal engineers: for those people, autonomy on my teams is always a given from the start. It is an expectation that those people are capable of taking a fuzzy requirement and turning it into something really concrete and then making a plan, doing research, executing on that plan. Um, when that trust is broken, that's where performance management kicks in. So I don't want to not trust people by default at that level.
It's the same philosophical idea of like giving everyone at your company their own credit card and saying, buy what you need to do your job versus having them submit an expense report for a $5 pack of pens or whatever. It's just the trust by default. And I think that can be very healthy. I think obviously there's organizational boundaries around that. I can't imagine Pfizer or a Fortune 50 company being able to do that with like compliance obviously, but a company like Multitudes or a company that's, you know, 50 people or less, I think that that can work fairly well. So autonomy by default.
[27:02] Laura Tacho: But again, What is autonomy? Because some people are going to say, I want to be able to pick what I'm working on and I want to be able to pick how I'm going to achieve it and I want be in control of my own roadmap but autonomy practically at your business might be, you know, here's the revenue goal and here's the projects that we have we're contractually obligated to execute on: so within those constraints, pick the right thing but we can't not do one of these because we've already signed the paperwork. We've already signed the sales deal, and those are really different environments to operate in.
So it's important to understand and help your team understand what the boundaries are around how much autonomy you can offer them. In terms of the cross-functional or cross-cultural differences in autonomy teams that are distributed need to come up with what's called a third culture.
So those of you who have moved around or grew up in different cultures are often called third culture kids. I feel like I'm not Austrian because I don't have an Austrian passport. I feel Austrian most days I don't really feel American anymore, but I grew up there and I have an American passport. So I belong to this like mythical third culture. And on your teams, you have to figure out what your third culture is.
It's going to come from sayings, it's going to come from communication practices, it's going to come from jokes. These are all really rich ways of figuring out what that third culture is. So even though you might have people from a culture with high autonomy, to a culture that likes a lot of structure. Putting them together, they’re going to come from from different starting points, but they need to come together and figure out what that third way of working is, what the way is that they agree. A team charter can be a nice way of doing this. There's some good templates — Miro has a really nice team charter template, which outlines what we do when we ask for help, how long we stay stuck on a problem, all of those things can help your team figure out what their definition of autonomy is, how they expect to work with each other and make that cross that cross-cultural international distributed team move a bit more smoothly.
[29:18] Lauren Peate: Great tips! Thank you and I see people taking notes. Well, actually, we'll do a Roundup after this as well, where we'll take some of the resources and I thank you to those of you sharing resources in the chat too. There's so many great chats here, but unfortunately… well, not unfortunately, but we're going to shift gears! Before we do that, I just wanna do a huge thank you to Laura for making the time and sharing your insights. There was just so many super actionable things. I'm bookmarking that question list right now. Thank you. Thank you! This has been wonderful.
Laura Tacho: Thank you. It's been great to have you all. Thanks for coming!
