Up and down the management track: Equalising your leadership style across the pressure of scale transcript

Hi everyone. Welcome to up and down the management track. First up, show of hands. Who here is a manager? Woo. Okay, there's a lot of you. Uh, hands up if you are a manager of managers. Okay, good. And hands up if you are a manager of managers of managers. Okay, cool. Some of some of my people here. Um, any IC's in the room? Okay, some of you. Um, spoilers. Cool. So, hi, my name is Karen Lee Rigg. I am a director of engineering at just takeaway.com.

And today we're going to talk a little bit more about my unconventional career journey. So, a lot of career talks go in one direction, which is up. This one, not so much. So, I like to call myself a classically trained software engineer. So I've got a degree in computer science. I was a software engineer for about six years and after that I moved to a company called Thoughtworks where I was a senior consultant. I was a tech lead was my first taste of leadership.

After three years of that I joined a startup called Peritive where I was a lead engineer leading a team of five. Then after a while I grew that team out. I was managing managers. I became a senior engineering manager. Then a little more time I became a director of engineering managing managers of managers. Cool. Then surprise redundancies and a reorg. I found myself managing managers again and then stuff happened again.

Now I was managing IC's and that was my time at the startup. My next role I took a head of engineering role at Jet. So this was uh managing a team called partner management. So it's about 150 people. Then after about a year of that stuff happens. We had a reorg. We decided we wanted to merge the second and third layers of management. So I went from managing senior tech managers to managing tech managers. And then again like as Mary said, eight months ago, I got promoted to head of engineering.

So, as you can see, my journey kind of goes up and down. And I'll be honest, every time I went down, it felt like a setback. But every time I went down, I realized it wasn't. And today, I want to show you what I learned at each level and why the direction of travel matters less than you might think. So, the transition from IC to manager, I've only done this one once, but it was the most memorable jump for me because the hardest thing for a software engineer to do is to fight the instinct to dive.

So, I got two stories here. First one was I was in consulting. So, I was working at Thoughtworks. I was a senior engineer. I was going in to do an assessment at a new client and it was a team of about 200 engineers. I had to talk to about 40 engineers in one week. And what I found was every single time I talked to one of the engineers, whether it was a head of engineering or a staff engineer, they would tell me about their technical problems.

And my gut instinct was to dive in and help them solve those technical problems. But as you might imagine, 40 engineers in a week, there's just not enough time. I can't dive in and solve every single person's problems. And my team had to almost pull me back by the scruff of the neck and say, Karen, we don't have time to dive right now. Stop diving into the problems. We're going for breath, not depth. So, as an engineer, your feedback loop is tight, right?

Take it in, take it out. Problem solved. When the moment you become a manager, that feedback loop disappears. Your job is no longer to solve the problem. It's to make sure the right people are working on the right problems. I got to lead five different tech stacks. iOS, Android, web, Scala, Haskell. And when I joined this company, I naively thought to myself, huh, I'm a tech lead. I'm going to dive into every single five of those tech stacks with my objectoriented net background.

It's not possible. You just can't do it. Not enough time in the day. genuinely did not have enough time and also not enough mental capacity to dive deep into every single one of those tech stacks fresh. But that ended up being a blessing in disguise because it forced me out of the technical detail and it forced me into proper people management. So the one skill that unlocks at this level is letting go. And what I mean that by that is not just delegating tasks but genuinely letting go.

Letting releasing your grip on how things get done. And this is the hardest thing that a senior engineer will ever do. But once you do it once, you suddenly get it and every level above it becomes easier. So what did I learn going from my C to being a manager? Fight the instinct to solve all the problems. It's a really satisfying thing to do, isn't it? Solving problems. It makes you feel smart. You get a dopamine hit from it.

But that's not your job anymore. Instead, you need to focus on how to support your people in solving the problems. To shift from answering answering questions to asking questions, from solving to enabling. You need to create space for your team to learn to do what you were really good at. So, the goal is to make yourself unnecessary for the day-to-day so that it frees up your time to do what only you can do. Now for those of you who want to deep dive into this topic, uh, Anamarie is doing a talk today at 505 on stage three called 400 tech leads.

Same problems, none of them technical. Highly recommend that one if you want to deep dive. So the key takeaway here is as a manager, if you are still the smartest person, the smartest technical person in every room, you're doing it wrong. So then the next transition from managing IC's to managing managers. Now I've done this direct transition just once, but I've also been at this level three times. And when I compare the first time to the third time, I realize I kind of sucked at it the first time around.

And I was actually a lot better at it the third time, as you might expect. Now, what didn't I do well the first time? When I reflect on this, the reason I didn't do well is because I was so focused on managing my managers. I wasn't doing the rest of my job. And also because at that point in time, I didn't know what the difference was between managing IC's and managing managers. So here's what I learned. First level management tactical.

It's day-to-day operations, right? You're running standup. You're doing retros. You're checking with your engineers every day. Second level management, you have to shift to be operational. You're responsible for the execution across the entire domain, not just of one team. You don't have time to be in the day-to-day. You need to set the ways of working and the structure to make your domain successful at execution. So for example, if you're in a smaller org, this will be stuff like team structure, delivery cadence, reporting, engineering standards and principles, performance calibrations.

If you're at a larger organization, this will be stuff like dependency management, portfolio management, stakeholder management, navigating the organization, resource allocation. Now again, I've been at this level three times and I've had the privilege of also managing this level as well. So here are some mistakes that both I have made and I have seen other people make. First one, only looking down instead of sideways and up.

What I mean by that is only looking at your team. So this was my mistake, right? I only focused on my managers managing their teams and I didn't do anything else. Second mistake, thinking, "Oh, all good. Well, then I'll just manage sideways enough." Now, you can't do that unless you've got strong foundations to begin with. So, you have to set the strong foundations, finish looking down first and then sideways and up.

The third one is expecting your manager to own your career development. Because at this level, your career development is not your manager's job. It's yours. Instead, you do what I like to call 360deree management, right? Which is manage down, manage sideways, manage up, and manage in. You might think, cool. All right. But what does it actually mean to manage down, sideways, up, and in? Managing down is no longer about managing individuals.

It's about creating space for your leaders to do your job. So the first thing that you have to do is make sure you have the right people in place. You have to have the right people in place. You have to develop your nose for talent. You have to trust them to do their jobs. So you have to create space for them to do the thing that they're meant to do. But you also have to give them a safety net which is the verify. And that safety net is creating a feedback network.

Now notice I say network, not a loop. And what I mean by feedback network is you have to create psychological safety not just with your skip levels which is very important but also your diagonals your cross functional diagonals which means your tech manager or engineering manager's product counterparts delivery counterparts. You need people to feel safe to tell you when something is not going right. And the last one is focusing on outcomes, not activity.

If your team is always busy, but they're not delivering anything, that's your problem. So for those who want to deep dive into the topic of managing managers, Susan Bond is running several round tables in the director plus track about managing managers and I highly recommend that one. So the next one is managing sideways. What does that mean? I like to describe it as basically just building relationships with your peers, but also doing it in a very specific way.

So, it's not just enough to be like, "Hey, cool. Like, I know your name, you know my name, like we hang out." It's not good enough. You have to approach it with an abundance mindset. An abundance mindset is the belief that someone else's success does not take away from yours. They can be successful and you can be successful. It's the belief that there is enough to go around that there are plentiful resources, opportunities and possibilities available for everyone to be successful.

This is opposed to a scarcity mindset which is if they succeed, I cannot. That's how you fail at managing sideways. So if you want to be successful at this, you make your peers successful. The third one is actually my favorite topic which is managing up I'd like to boil it down into two things. The first one, make your manager's life easy. I'll give examples. My previous manager when I was head of engineering, his name is James.

James can come to me with any outcome he wants to achieve and I just make it happen. Don't need to involve him. I don't need to ask him for help. He just tells me exactly what he wants. Poof. Magic. The second one, oh I forgot to mention as well. The other thing I do is if I do need to escalate, if you ask me to do something, I do need to escalate, I tell him who he needs to talk to, what he needs to say, and make his life really easy.

And the second one is making your manager look good. And the reason for this one, if you look good, they look good. If they look good, you look good. You want to take that off of their plate so that they don't have to worry about watching their back. And also, as a bonus, if you make your manager look good, other managers see that, too. You suddenly become an incredibly desirable direct report. So, if a new role opens up that you're interested in, that's how you get to the top of that list.

Now, it took me a couple attempts to get this right. And the only reason I did this really well in my last role is because I was a third level manager managing second level and I knew what I expected from second level. The last one is managing yourself and there are a few talks about this particular at the director plus level. Leadership gets hard especially as you go up. There's more ambiguity, there's more pressure, there's more visibility and there's more at stake.

Your team takes emotional cues from you whether you intend it or not. If you're anxious, they're anxious. If you're steady, they're steady. Now, this doesn't mean pretending like everything is fine. It means processing your own reactions before they become your team's problems. Knowing when you need to step back and regulate and respond rather than react. Sorry, that was managing. The second one is actually owning your career.

So at this level I mentioned earlier, if you need to be told what your next step is, you're not ready for it. Nobody is coming to hand you a development plan. You need to know where you want to go and understand the gap between where you are and where you want to be. And you need to actively close it. So that means seeking out feedback, investing in your own development, coming to events like this. You have to take accountability for your own growth rather than wait for someone else to drive it.

So the key takeaway for second level, the most important work is not below you. It's sideways up and in. If your calendar is full of skip level one ons, something is wrong. Now what goes up can also come down. I went from managing managers of managers to managing managers to managing IC's in a very short period of time and it felt like a really big step back. But then the second time this happened when just merged layers I went from head of engineering third level 150 people down to second level 30 people.

And how did I feel about it? I mean my team's here actually it was great. Um, it wasn't ideal, right? But the way that the directors had sold it to me and the way the CTO sold it to me was Karen, they said to me, Karen, groceries and retail, which is the team that I led, groceries and retail is the most important strategic initiative for the business and we need someone who is overkill for this job. And that changed how I thought about it.

Anyone heard of Everest? Yeah. So when climbers climb Everest, they don't just go straight up. The mountain will kill them if they try. Instead, they follow a really deliberate process called a climatization. So that's where you climb to a higher camp, you come back down again. And then you climb to a higher camp, you come back down. And this lets their body adapt to the altitude. Then they repeat the cycle before the final summit push.

So each descent isn't a failure. It's what makes the next descent possible. Now going down a level in management is very similar. It's not regression. It's a climatization. You're taking the opportunity to build the capacity, the relationships, the habits, the instincts that you couldn't fully develop when you were pushing upwards. And just like on Everest, the climbers who skip that process, they're the ones who don't make it.

Anyone see like mobile game ads like this one? Yeah. It's like they show you a video of someone obviously playing it wrong and you're like, "Oh no, like I I got to download this app now and I got to play it right." That's kind of how it felt for me as a head of engineering watching my second level managers do their jobs. It's like but that's not how I would have done it. So going back down a level actually gave me an opportunity to scratch that itch to build something that I thought I could and do it in my way.

And what I actually built was a leadership team that operated autonomously. And that freed me up to do what I never had time to do before. Building relationships, building my network, operating sideways properly for the first time. And this year and a half at second level is what got me to director. So really, a step back is only a setback if you treat it like one. The climbers who don't make it up Everest are rarely the ones who descend too many times.

They're the ones who didn't descend enough. And if you go back down a level with the skills that you built above it, you will do that level better than you've ever done it before. And that acclimatization it was is what makes that next summit possible. So now I've made the transition from management track to executive track. Cool. Now I'm in the room. I'm part of the senior leadership community. I have a seat at the table.

I have made it to the top of the totem pole. Reality check. There's 150 people in the senior leadership community. I am not at the top of the totem pole. I am just at the bottom of the next one. I am still but just a grunt. And now I have a whole new set of skills that I need to learn. So switching from execution to strategy. As a manager, you lead individuals. As a manager of managers, you obviously lead managers. As a manager of managers of managers, you lead organizations.

And leading organizations means building systems, not managing people. Your job is to design the structure, the incentives, the culture that will produce the outcomes the business needs. Which means you have to deeply understand the business first. And when I reflect on the businesses I've been on at third level, I think about the differences in scope and scale. So when I was at the start, I had a really big slice of a small pie.

At enterprise, I have a really small slice of a very big pie. And being at this level at different scopes and scales, this is what I've learned. Three things that matter most at this level. The first one, make the right decision for the business first and then execute it in the best way for the people. And you might say, "Oh, but Karen, like people are important too." Yes, people are important. People are super super important.

But if there is no business, there is no people. So you have to put the business first. And that means strategy first, structure second. And this sounds obvious, but a lot of a lot of leaders get this backwards. When you first move into third level, the instinct is to work with what you have to organize around the people, their strengths, their existing relationships. But that means your structure is shaped by historical accident, not strategic intent.

So the right approach is to start with a question. What is the best decision for the business? What does this organization need to achieve in the next one or two years? and what structure gives it the best chance of doing that. Only after you have that do you place the people? And sometimes it means hard conversations, sometimes it means roles don't exist yet or roles that need to change. But a structure around strategy is one that actually can execute compared with a structure built around people which results in drift.

The next one, the blast radius of a bad hire is enormous. enormous. At the first level, a wrong hire affects the team. At the second level, it can affect a function. At the third level, a bad hire in a senior role can misalign an entire domain for probably 12 to 18 months before you fully understand what went wrong. So this means your judgment of people not just their skills and experience but their values their self-awareness and how they operate under pressure becomes one of the most critical skills you can have.

So at this level you have to slow down on hiring decisions and if you have the wrong person you have to exit them quickly because the cost of a vacancy is almost always lower than the cost of having the wrong person in place. Now also at first and second level you can course correct through proximity. You're close enough to the work and the people that if something goes wrong you can spot it and fix it. At third level you cannot be everywhere.

You have hundreds of people making hundreds of decisions every day that you will never see. And the only thing that shapes those decisions consistently is culture. And this is when it clicked for me. Culture isn't a values poster that you just put on a wall. It's an operating system. It determines what people do when you're not in the room. What they prioritize, how they treat each other, what they're willing to raise, and what they're going to stay quiet about.

You don't build it by just saying, "This is my culture." It doesn't work like that. You build it through what you reward and what you tolerate and what you model yourself. So at enterprise scale, the gap between the culture you think you have and the culture you actually have can be enormous. And that gap is almost always explained by the behaviors that leaders tolerate somewhere along somewhere along the way. Now I want to note each of these topics can be a whole talk which is why I'm happy to discuss further in office hours.

But if there was one point I was going to expand on, it's this one because this is what unlocked third level for me the first time. What does it actually mean to be a strategic thinker? Very simple. First, brutal facts. Where are we now? Not what you think was, what you think is true, what you wish is true. What is actually true? Then second, where do you want to be? What's the end goal? You have to understand the business for this, right?

This is why strategy first, decisions for the business first. And then the strategy is basically how do we get from where we are now to where we want to go and not just well I think we're going to do it this way. It has to be a set of deliberate choices. It has to be what you will do and what you won't do and in what order. Now Alice Bartlett is doing a talk on this uh and the director plus track tomorrow at 11:30 for those who want a deep dive.

So at third level, if you're spending most of your time on people management, you're still operating at second level. Your job is to build the system that makes everything else work. You may have noticed by now there's a pattern and it shows up every single time you move up. At every level of leadership, what earned you that promotion is what's going to hold you back if you don't let it go. These are the success traps.

First level, you got promoted from an IC to a manager because of your technical depth. If you hold on to that, you will not progress. Second level, you got promoted because you were really strong people manager, but if you only focus on people management and you don't let it go, that will hold you back. Third one, you got promoted to third level because you ran a really tight operation. You were really, really strong at operations.

But if you hold on to that at third level, that's what's going to hold you back. So the thing that I realized is leadership principles also don't change regardless of level. So being in the senior leadership community now, I have access to all the senior leaders and this is what I've seen. First build strong foundations and then let go. This is picking the right people, trusting them to do their job, creating a safety net, and then focusing on outcomes, not busyness.

The next one, understanding where you fit, knowing the business, knowing how you drive value. How does your team fit into the big picture? Communicate a clear vision. Because if your people, no matter how good they are, if they don't understand what the end goal is, they can't execute. Fourth, culture is your operating system. What are you going to reward? What are you going to tolerate? What do you want people to do and say when you're not in the room?

And the last one is building a feedback network. Now, you see this at every level. Have you ever had those company surveys that ask you how you like working at your job? That's your CEO's feedback network, right? It changes with scale, but the fundamentals don't change. So, I'm going to end off with a reflection on my career journey from writing this talk, which is that despite going up and down and up and down, when I look at where I was the first time at each level and I compared to the last time at each level, I realized I still continued to grow and I still continued to progress.

And there were other dimensions that I needed to consider. scope, scale, impact, and it made me realize that I needed to change my perspective because what looks like a downward step could actually be a stepping stone. And progression is not just a linear path going up the management layers. It's a multi-dimensional, multifaceted journey through time. It just depends on how you choose to look at it. Thank you so much for having me. >> [applause] [music]