How Many EMs to Change a Lightbulb?

Speaker A: Kobe might have his coach on the floor when he's doing his shots every day, but Kobe is the one putting up the shots. Kobe is the one who is sitting there doing the work. And this is where I think we flipped it around. Everyone wants a manager who is going to say, I am there. I'm going to advocate for you. Yes, they can do that. I'm going to coach you. Yes, they can do that. But for whatever reason, we feel that it's become the manager has to do the work, not the person, because they view that they're doing the work in the day to day job. That is not true. You have to do above and beyond the day to day job if you want to progress above and above the day to day job. And it's on the individual welcome to

Speaker B: Developing Leadership, the podcast for engineering leaders where Aizo Kent and Jason Werner share their lessons on the ins and outs of managing software teams. On today's episode, Jason and Eizo explore the implications of Mark Zuckerberg's plan to flatten Meta's management layers and examine the current ratio of engineers to managers, questioning if this balance is truly efficient or if it's simply a byproduct of Silicon Valley culture. As always, this episode comes with accompanying show notes with a deep dive into the main topics, mental models, and key moments from this episode. You can find them at developingleadership.substack.com where you can subscribe to get weekly content in your inbox.

Speaker C: Developing Leadership hi everyone. Welcome back to yet another episode of Developing Leadership. Hey Jason, how are you doing?

Speaker A: Pretty good, pretty good.

Speaker C: So we were having a chat, uh, and I guess we're keeping it very current at the moment. Um, the flattening of Meta, what Mark Zuckerberg is doing. Can you maybe give a description to those listeners who aren't familiar with it, uh, on what's going on?

Speaker A: Yeah, it's always odd because we record these things in one moment and post them, uh, a couple weeks later. So, you know, we never know what's going to happen in between recording and posting. So for the record, we're recording this in, uh, mid February is what we're doing this. But, um, well, two things. One, is it Meta now or is it going back to Facebook? Because they just announced that they're going to change the ticker back on Nasdaq from Meta back to fb. So I'm not really sure what's going on anymore. What are we supposed to call this thing? But anyway, here we go. There's been some hubbub uh, that, you know, Zuck is gonna take Meta or Facebook or whatever it is and basically flatten the Org, which is, you know, you can think of this as a quote unquote, span of control issue. Like how many people between Mark himself and, you know, random engineer, random IC marketer, random whoever inside the organization. How many people, you know, Mark? Some VP or maybe multiple VP layers. Vp, vp, vp. And then maybe a, you know, VP to director to senior manager to manager to engineer or something like that. You know, call that span of control. How many, how many layers is that? Is that, you know, three jumps, five jumps, eight jumps? How many layers? So sounds like that Mark is going to flatten this. It's going to remove some of those layers and, um, you know, see how that goes.

Speaker C: So it's funny because I've been thinking about this a lot this week, but absolutely not in the context of Meta. I've been thinking about how, as technology progresses, how many managers and leaders do we need to ratio of engineers? Because we're currently living in a world where it's not uncommon to find, um, take a small engineering work with 100 people to have over 30 leaders, which to me feels completely crazy. Right? But if you do the math right, and I'm probably going to mess up on the math, sorry for those people,

Speaker A: it's a Friday evening here.

Speaker C: But if I take five engineers to a manager or to a team lead, which is pretty common these days, and I think that's a whole discussion on its own, we need to have. And I take 100 engineers. Okay? So I'm at 20 team leads. Right. Okay. It's probably a little bit of an exaggeration, but there's organizations like this, but

Speaker A: you're not orders of magnitude off. Most likely there's probably 15. Right, exactly.

Speaker C: Yeah. And it's because we got 15 team leads. Now, I've seen plenty of organizations where it's two to three team leads to an em, right? So all of a sudden, let's say it's three. And I'm giving a lot of credit here because in many organizations it's not. We've got an extra five leaders, uh, at this point as like senior ems. Now then it's not uncommon to find a director for every two or three ems in, uh, an organization. And then we ADD on a VP and a CTO, and before we know, we're at what, 25, 26 engineering leaders to 100 engineers. Now, this makes no sense to me, and I don't think it makes sense to you. Either. So let's start like, yeah, unpacking this.

Speaker A: Well, I think this goes back to the notion of how. Let's decompose this a little bit. What is a leader? What is an engineering manager? What is a leader inside the organization? How many people are manager's supposed to have reporting to them? And also just general excess inside Silicon Valley and what people are allowed to do now. You know, I have my own lived experiences and mistakes I've made and things I would do differently in the past and stuff. But I, I will genuinely say that I think the current state, where we're at, where, you know, let's say that most people will say, hey, I'm, um, on my sixth, seventh, eighth engineer on um, that capacity. Therefore we're going to move on and start splitting the team. Therefore I will create two, if I'm a manager, I'll create two teams. Hire a manager for each one of those or hire a team lead for each one of those, or promote somebody. And therefore I can expand to, you know, 12 to 16 people or something along those lines, therefore getting my own promotion along the way. Because now I'm not just a manager, I've got to be a senior manager there too.

Speaker C: So let's take a second and decompose the role of a team lead or an em. I mean we use so many different terms, but let's just put the most, the one I dislike the most, but it is the best explanation. The line manager. Right. Someone who manages engineers directly, uh, into what their role is. Right. And I've been thinking a lot about it this week and you know, very high level, we can think about it on the people side and on everything that needs to be delivered side. And if I look on everything that needs to be delivered, I look at, you know, planning, prioritization, identifying like improvements, trying to get ahead of issues, helping with technical decisions like goal setting, being this communication bridge, right. From developers to like senior manager. And then we have the actual coaching, mentoring, helping someone in their career. To me it feels that that first bucket is going to disappear over the coming several years. And what I mean with disappear as in we're going to get machines that are going to be way better at doing that than we are ourselves as humans.

Speaker A: Way better at doing what?

Speaker C: Yeah. So estimating how long a JIRA ticket takes as a manager. Right. Taking the inputs from the engineers and of course with quantitative and actual data as a Manager, I think 1, 0 for, let's use the dirty term, AI. Now, prioritization, well, I think a lot of that is going to come from again, the product side of the house, the business side of the house and the engineers. I think the manager, the time that needs to be spent on decision making, on um, prioritization is going to reduce identifying where we should focus and where to improve bottlenecks, issues, process changes, which

Speaker A: again is engineer on one side of a fence.

Speaker C: Exactly.

Speaker A: On another side of the fence side of sense.

Speaker C: You know, I mean, and then again I see that as a smart system in between there now being a communication bridge between the management above you and the developers. That to me is dead.

Speaker A: Well, let's talk about some of the things that have allowed that to be. So right now in Silicon Valley, obviously we're going through a shift 2022 and 2023 with the market corrections and liquidity crunches and all those sorts of things that are happening. There's a whole bunch of different effects, et cetera. But from 2005 on, outside of that blip in 7 and 8, which didn't really affect tech from that perspective, we had this massive bull run. We had excess everywhere, all that sort of stuff. Um, I remember the term shit umbrella came out of Google which was like, hey, we need an engineering manager because they're the shit umbrella that, you know, protects the team from the org and stuff. Well, that's a reaction to a specific environment. That's not what an engineering manager is supposed to be. But somehow that's become a thing in Silicon Valley. And then there's the product manager, which is the mini CEO of the product, which is another reaction to another organization. There's like these weird reactions that have happened to all of Silicon Valley based upon like the context of what? Of one or two specific organizations over the last couple years. And then with excess and people not knowing how to do their jobs, they become the norm. Um, so I think you're entirely correct. But I also think that we're well past the point where we should have understood that an organization of 100 people with uh, 15 people leaders inside the organization, is not a well balanced organization. That is not what we should have been for quite some time.

Speaker C: Well, it makes me think of the um, you know that lines of communication chart that you often see like next to Brooks Law.

Speaker A: It's crazy, right? When you see it put in practice,

Speaker C: when you actually see this, right. It's like it's, it's not that having half the leaders is, you know, like twice as good in this case. Officially, it's. No, it's, it's massively so. Like you can't put 15, 20 people in the same room.

Speaker A: People don't understand. Ultimately when uh, when I went in my GitHub experience, right, so remember when I joined GitHub was obviously an especially dark place when I joined. But I said I want product, I want engineering and I want design minimum and I want everything under engineering. So security, data and infra application engineering community. I needed it all because I needed everything that was related to all the product stuff. And I got a lot of pushback from the board and they were saying that doesn't seem like it would be, it would make sense. We like to have tension inside the org, like well fuck you guys, you don't understand what's wrong with this company. Then if you want tension in the org, this company hasn't delivered in a bunch of years. And so you didn't need m more people to convince. You needed a singular person who had a vision and a voice to put this thing on the right track again. So the risk in me was I was the wrong person. But the risk in bifurcating me and putting two or three or four more people in place was exactly what you see inside organizations once they get these lines of communication. Four points of view, four opinions, four different people that have to be involved, four egos for all those sorts of different things. Things. It's almost impossible to break inertia in those types of situations. And this at the root of it is what we see layers down when you've got four or five different teams trying to communicate with each other and they can't align on a roadmap.

Speaker C: So let's kind of tackle this from both sides, right? We have um, the five person engineering team to a team leader, em, um, uh, in one environment and then we have of course the meta situation of like hey, we need to just crunch middle management into less layers so that we can actually get stuff done. But if we. I like to take. I was having this discussion this week and I was pushing to someone I know and I said is it 25 engineers to a team lead? Is it 10, is it 15, is it 50? Right. Like of course knowing that those latter numbers are a little ridiculous, but like where is the limit and what defines the limit? And I'm curious to get your take on it.

Speaker A: So I don't have an answer to that question either. But I will say that when I was an up and coming engineering manager and this is before GitHub, even before Heroku, but canonical, at one point I had 38 direct reports and I mean obviously if you say that people are like, that doesn't make any sense. How is that even possible? Well, even at the time I was like, this doesn't make any sense. How is this possible? But necessity is the mother of all dimension type of deal. You just figure it out and you start to really understand how to get efficient, how to get good, how to, how to do that. And the irony of that situation is that singular situation probably prepared me more for understanding how to run very large companies than a lot of other things. And yes, it's the totality of my experiences made me who I am. But would I have ever been a very good product engineering design type of like meta, uh, CTO if I didn't have that experience of having nearly 40 people, you know, probably would have been a lot harder to become that person.

Speaker C: So where does the bound, like, so I do think where there's a boundary to be set, right? So if we take, if we look at as the two parts of an engineering leader's role, the parts that are likely to be heavily assisted and partially automated, right? And then the parts that are less likely to take humans out of the mix, so to say like, you know, the fostering great cultures and resolving interpersonal conflict and like, and building trust and such. Ah, you know, as a, uh, on the people side, you are there to coach and really bring the best out of people. Let me ask a very tactical question. How many hours a week should a team lead spend with an engineer on their team to help get them to the best place for them for their career and for the company, like as a whole?

Speaker A: I would say on m. The minimal side. Um, I don't think this is something that we should be massively investing in. And the reason why I say that is because the orientation in what I think has happened is that the manager becomes their coach and the person almost responsible for getting them there. And that's wrong. That's the wrong orientation. It's the individual who is responsible for getting themselves there now, their manager, the coach, whoever can guide them, say this is what I view to be next steps for you, all that sort of stuff. But how long does it actually take to put that in place? You know, in a situation that's minimal amount of time, there doesn't need to be a lot of conversation that happens there. And the most involved people in their own careers and their own uh, or their own progression can amalgamate that information really quickly and go back and work on it themselves and all that sort of stuff. But like literally it could happen in less than half an hour each week. It could happen in less than half an hour. Once a month it should happen. It could happen in less than half an hour. This is not an involved conversation. It's you know, how much are you. Can you actually convey that someone needs to go and work on. So this one hour a week or half an hour a week one on one where we kind of go through all the things, we do all that sort of stuff and we blah blah blah, that sort of thing. If you step back and look at that, what is actually being achieved in those sessions I can tell you the probably very minimal. And this also goes to one on ones are not about work. They should be about the person and that sort of stuff. That whole notion of things. Well again like no, that's really not true. One on ones if you're going to be doing them in to that degree in capacity need to be about work because you're spending that much time. If you have eight team members and you're spending an hour a week, that's eight hours for one manager. If you have half an hour, it's four hours a week. And I say that's not that much of investment. Well, it's a tenth of the week if you're only working 40 hours a week. Like it's you as a manager like your responsibilities and all that sort of stuff. Like you should be able to convey that to somebody super quickly and they would be the ones doing the work. You're not doing any of the work to bring somebody up and you shouldn't be doing that work.

Speaker C: Again.

Speaker A: That's you're showing them how to do this. This goes back to like this is. Go back to sports one more time. Kobe might have his coach on the floor when he's doing his shots every day. But Kobe is the one putting up the shots. Kobe is the one who is sitting there doing the work. And this is where I think we flipped it around. Everyone wants a manager who is going to say I am there. I'm going to advocate for you. Yes, they can do that. I'm going to coach you. Yes, they can do that. But for whatever reason we feel that it's become the manager has to do the work, not the person because they're doing the work in the day to day job. That is not true. You have to do above and beyond the day to day job if you want to progress above and above the day to day job. And it's on the individual.

Speaker C: So let me throw something out there at you. Do you Think that the manager is always the best coach?

Speaker A: Oh, no, God, no. No.

Speaker C: And I don't mean that. No. But I don't mean that from the fact that there's lots of bad managers. I see. Like, even if you have an amazing manager, are they the best to be the best coach?

Speaker A: No. And the reason why is because not everyone needs the same coaching. And you know, some people need a very specific type of coaching and some people need a, uh, more generalized type of coaching. And some people need to be called out when they're bullshit and they're. And some people need to be, you know, whatever type of deal and there's different types of egos involved and it's weird, but. And some people won't learn from a direct style, some people won't learn from an indirect style, like that sort of stuff. It's kind of strange if we as individual employees inside of a, you know, society right now, put everything on our company to provide for our needs. As we've talked about in the past in this podcast, it's a road to failure because companies are not structured. They're not supposed to provide all of the needs for us as humans in our lives. Well, it's the same thing with a singular individual manager. If you expect your manager to give you everything, you need to be your coach, confidant, mentor, BS parameter, all that sort of stuff in your career. No, that is not actually one. That's not what leaders are supposed to be doing inside their organizations, you know, full stop. That's a portion of their job. But if you expect it out of a singular person, you know, you're in trouble. You don't read just one book to satisfy your sci fi needs or whatever it is. You read multiple books, or you don't just search once in Google and say, the first link is the one I'm going to go, and that becomes my personality on this topic. You start to like, it's the same thing, like, you know, read multiple sources, go find different avenues for these things and amalgamate it and you could use your manager as one input source.

Speaker C: So let me put this together, right? We advocating for a manager absolutely should be a coach, but it shouldn't be someone who's doing the work. Which means, you know, half an hour, a week, an hour, you know, a week, maybe like depending on the situation or even less. Uh, and we feel that a lot of the work that they're doing today, this, you know, being communication bridge and, you know, planning and prioritization, all of these things are going to get more assisted and go a lot faster. So what are we doing? Like uh, where, where do we want our managers in three, four or five years from now to be spending their time as more and more time is being given back to them?

Speaker A: Also describe one more like kind of failure scenario. I see. And then I'll answer that question because I think it's related. One of the odd things is that as you progress more in your career, you're going to need less, but also expect less out of other people. It's like, you know, no one asks me now uh, about those types of things and they shouldn't because this is Right. But we have the more junior people mentored by the most junior people in terms of the leadership. It's kind of this weird cycle if you think about what's happening.

Speaker C: It's one level above you is where

Speaker A: the um, it's one level above. It's. It's basically the person who read the page before you coming into class trying to teach you type, type of stuff. And it's, it doesn't make a lot of sense when you think about it really quickly. So what do we get? Well, I think the reason why a lot of those expectations are what they are is because of uh, exactly that situation. Right? Like in fact the engineering manager has no idea what they're doing on this in general. So like that's why it's inefficient. They spend a ton of time and all that sort of stuff. But what I think we, we should expect out of managers and leaders in general, it goes back to what we talked about before ultimately, which is outcomes and outputs. The job, uh, always has been to produce. But we've lost sight, I think of that because that's a byproduct, you know, that's quote unquote a byproduct of maybe the constructs or the situation or the org structure and. Well, ultimately this goes back to the fallacy of engineering, which is if you build the perfect system, everything will be great. If you build the perfect architecture, you'll never have to worry about it. And like this again, like we know that not to be true. And the worst performing companies in the world who never ships because of how risky it is, or maybe the code's not clean or it's not the perfect architecture or whatever. Well again, kind of going back to that, we don't have that in orgs, but for whatever reason we kind of feel it. So we need to produce more, we need to have the outcomes more, we need to put the Engineering managers and leaders and others responsible for that. And, and, yeah, part of that is going to be helping their folks achieve certain aspects of things. But it's really helping in the fact that I have empowered them to be responsible for themselves. I have told them my opinion on where they think they should probably work. It's on them if they want to go do that work and that sort of thing. But I, as an engineering manager and a leader, I'm going to be focused up, uh, not up the chain, but up on what the company needs. And so what are the outputs that we need from an organization? What are we supposed to be working on? What are we supposed to be doing? That sort of thing. So going back to that shit umbrella thing from Google, which is like, I'm going to block this and do this. Like, well, no, we actually know you're supposed to be looking up this way. You're supposed to be figuring this stuff out and then coming down and saying, like, this is what we're going to go do. Yeah, you go, you do need to go work on that. So go work on that. But, yeah, this needs to be achieved.

Speaker C: But aren't we usually blocking team leads and ems to that? Because in many organizations they're, they're becoming, you know, ticket machines. I don't have the, I don't have any input on what I get to decide that I work on. It's. I get these seven tickets this week, and that's what we have to deliver.

Speaker A: Uh, engineering managers listening to this are going to rail. They're going to hate me or us, uh, or whatever for saying some of these things, because they're like, you don't understand. Like, I do understand, but what I understand is that the entire Silicon Valley kind of mechanisms are broken across the board. And if you've been a longtime listener of this podcast, you'll know the following statement has been said probably more than anything else, which is, there is no real leadership in Silicon Valley. I don't believe, I mean, I believe that there is so few actual real leaders in Silicon Valley that what we end up having is these dystopian, weird, baroque Rube Goldberg machines of organizations, like these things, like, like, go look at Google, go look at Oracle, go look at any of these organizations, and you'll understand that, uh, when I say we need more leadership, uh, we need individual line manager leadership, absolutely, as we're talking about here on this podcast. But we need senior leadership. We need senior leaders who actually know how to do this. And so my real point here, for the past 20 years we've not been. The Silicon Valley has not actually produced good leaders. And, and I think it's because of the way that we're, we're doing this. We're putting on the individual engineering managers to produce these leaders. And they can't because of that system before, which is like the blind leading the blind to slightly less blind, et cetera, et cetera. Keep going up the stack and maybe one or two people or a handful of people are able to like escape out of it. And there's always going to be that 2% versus 90, uh, 8%. And we, and those of us that have been able to figure it out, we always opt out because we're never going to go put up with the bullshit. So going back one more time, I get the call all the time from all the senior jobs in every single large big tech company for massive dollars to go fix their organizations. But what they don't understand, and I've said this multiple times, is I will never take any of those jobs unless I can fix everything, because everything needs to be fixed. And Google is the best example of this. Google is a company that is on a, has one of the best market positions of any company in the industry. And if you cannot take, uh, a top five job at Google where you can affect everything, you are just going to go in and bang your head against the wall because it goes to hiring compensation incentives, the way it plans, the way it's organized, that sort of stuff. And if you can't fix that, you're fucked. And so you can't take the head of GCP job or the head of YouTube job or whatever unless you can control every single thing inside your domain. And the way Google structured is you can't do that. And so you don't understand what kind of pain you're in because it's structured in such a way now no matter, no matter your title, no matter your pay, you're a cog in the machine. And many people will say, well that's, there's an intention behind it. Yet there was an intention behind it and it was so that no singular bad leader could take down the entire ant colony. But the point being now the ant colony is very mediocre and it doesn't know what it's doing. And they have to actually go back on a Newton's cradle sort of pendulum and they have to swing the other way. They need to bring somebody in who's going to say f all that, sorry, that was great to get us to where we were we love it, we're going to sunset it and we're going back this other way and here's how we're going to do it.

Speaker C: And I guess this brings us back to Mark because it does uh, seem like he over the last year started doing that.

Speaker A: Which is why like all of us who, who look at this might like rail on Facebook, XYZ in the past or whatever we say like, well, that it's possible because Mark is a singular voice who could change the entire thing.

Speaker C: So you think he's going to succeed?

Speaker A: It's a, it's a force of will thing. And so there's the risk of failure of all startups. Like no startup should exist in the world in the first place. Like the percent chance that any of these things are successful over a long period of time is, should be zero. Like effectively is de minimis. You get to the point where like it is successful. Like you can't bet against them each time over and over again. Now each time it becomes riskier and riskier. It's kind of one of those like um, statistical things. But you know, it doesn't take a lot look to ultimately change these things. It actually takes, it takes firing only a couple of people before you can actually dramatically affect change. And that's really what it comes down to. Like we've talked before, where is. Here's my GitHub notebook. I always have it next to me. Right. Um, and so I have various versions of these um, for companies and Google is one that I keep always up to date just because. Right. And so what, what do you do if you want to actually fix Google? And there's, we just, we just uh, today is February 17th. We just had that opinion article released on Google. Well, it's, again it's, it's not that hard to go fix Google, but it's a force of will thing. You need someone who is secure enough in themselves, secure enough in their job and understands that there's a short term and a long term thing that both have to be played out. So you can't just make a proclamation and then it's done. You have to make a proclamation and see it through. Like parenting, like consistently day after day, month and month, a year after year, push this. And again, not super hard to go do. But Google apparently does not have anybody at the moment who can go do that.

Speaker C: And to be honest, the point that you made on, you know, big change, consistency being the key, I think this holds true to anyone listening to this on any change that they're Trying to make that affects culture. It's the consistency at the end of the day because the organization is always going to try to default to its former state. Right? It changes. I mean there's way better things written about that. We can talk about change management but like fundamentally it's all going to try to come back to state that it's in, we're putting it in chaos. Right?

Speaker A: So there's only two possible ways in my opinion to dramatically change organizations. And they're at different ends of the spectrum and they're employed at different times and the two possible ways are all at once right away like bam, it's done type of thing. And the other is going back to that frog boil pot analogy and it's a consistent slow sort of thing. They're neither good nor bad. But I believe that those are basically the only two ways in which you can do it. And it depends on a whole bunch of different variables and circumstances and, etc, etc. And was uh, a Seinfeld thing, yada yada yadas of the world to like understand those sorts of things. But you have to understand that like there's no real middle ground on that. Which is why I think that some place like Google has to understand what are you going to do? Are you going to just bam, do the zuck thing and like eliminate 200 or 300 managers overnight and let the chaos ensue? Which is kind of like what we're seeing over at Twitter at the moment. But ultimately if you think about what long term it might look like is one thing or frog boy pop, you know, type of deal and you know, we could talk, we could talk at length about that for sure. One thing I'll mention um, is that when I was joining GitHub I got a lot of pushback um, on a lot of different approaches things. One of them was there was a various person who was very close to the company advise said hey, you need to go and you basically need to cut 50% of all the people inside that organization right away. Um, and I knew I couldn't. One, I'm not the CEO, two, I'm not a founder, three, I don't really have the positional authority to go do that. I can't go and like let go people in every single department and um, all that sort of stuff. And two, I knew a lot about GitHub but I didn't know exactly how over oriented it was, so wasn't sure. I didn't also think it was probably the right strategy for GitHub given, um, what I did know. So one of the things that I did is I obviously took a very intentional strategy for the frog boil pot and make exchange over here from a hiring strategy, make y change over here from an incentive structure. Do Z from a product perspective. You get the idea. You got to like, you got to put them all in place and there's a reason for each one. And one of the senior leaders inside the organization when I joined told me the same thing because they're close to this person. And about four months in we went on a long walk and they said, okay, never mind. I totally understand exactly what you're doing and I want you to know I'm fully 100% behind it. I wanted you to do this other thing before I thought you were a weak person because you weren't doing it. But now I understand. And now I understand the genius of your strategy in this place. And I said, I. I said truthfully, I don't think there's much genius. I just don't think I could have done the other one. Given a lot of other things. This is the only one I could have employed at the time. But what I did was I did this one masterfully. And that if according to their words, I should say there too. But like. And that's important. The point being that you have to really see these things through. You have to understand that it's going to be a grind and you have to put. You have to keep doing it. There's no just like set and forget in each one of these.

Speaker C: But I think the uh. And you said it already, right? Someone's not a founder or someone's not a CEO can pretty much not be fired. Right. Uh, it's incredibly hard to do these things. Ah. At particularly these large public companies because the amount of backlash, that comes instantly. And I think Meta. The only reason Meta is able to do it is because they aren't in the best possible spot. If they were in an incredibly good spot from a business perspective, it would be almost impossible to do. And that's the problem Google has. Right.

Speaker A: Well, so look at Google and Microsoft, the difference in turnarounds. Sundar came in and it was a golden run and it need. And he just basically kept the golden run going. So he's. He's a quintessential quote unquote, peacetime wartime. And I hate those terms, but you understand what I'm saying in that he basically saw this golden run and saw. But Microsoft Satya came in at one of the lows of the low and yeah, there's like a lot of people who love Ballmer and talk about that, but the stock was tanked and public market perception was blah. And yeah, maybe again Ballmer internally did a lot of good things, but Satya had carte blanche because everyone thought they were on a road to obsolescence.

Speaker C: I think that's going to be Google's challenge to its future, right? Until you're challenged really on the goose that lays the golden eggs, it's very, very hard to do so. And who knows, maybe some of the things that are shaking out right now with what I'm still skeptical of, but at least people trying to challenge them on search at least can wake some people up and, and hopefully change it. But it's very tough to imagine that going, going well. So we've looked at this from two angles, right? We've looked at this from the angle of kind of the, the line manager, the team lead, em, um, and the ICs and the fact that we've kind of gotten in a place where we're just assuming the default to be, you know, five to eight engineers to a team without questioning it within context. And on the other side we've looked at, you know, what does it look like at a huge org where we have all of these layers of management that are causing it to be incredibly hard to get stuff done. And then we've kind of discussed the future of engineering leaders as more of their tasks start, well, becoming assisted and more automated. So for someone listening to this in their org today, let me take a uh, you know, 200 person engineering org, SaaS company, you know, not the crazy big or not the small startup was listening to this and going, I see this in my org. We're 200 people, we have 45 leaders, we have guilds, we have all of this stuff and we're like, and it's, and it's slowing us down. Jason, I'm going to cop out here and ask you to give him some advice.

Speaker A: So I think it's kind of simple and it's same for almost any level, which is you got to be known as a person to get shit done. And if you're the person who's known for that, a lot of other things inside the organization in your own career are easy. They become easy mode for you if you're inside the organization that you see that happening. The easiest and best way to avoid all sorts of traps is to just take care of your area above and all else above all else, focus on getting all the stuff done. Two things I'll say here and then I'll move on to some other specifics. One is the person who constantly gets things done and ships is actually given more, more responsibility, more people, more money, more whatever. So if your goal is actually career progression, your goal is all that sort of stuff, ship, ship quality, ship, high quality stuff that makes an impact and you're going to automatically be given more. And in fact there's that old saying which is take problems off your boss's desk. Easiest way, easiest way ever to do that is take more problems off your boss's desk, make it so they don't have to think about you and you're going to get it. And there's a natural reaction for many people to say when a boss, uh, tells them to go do something or says, I need this done, is to ask 15 questions. Just say, hey, I got it, I'll figure it out. And that's what you do. You go figure it out. The second thing is, if you're inside your organization, see this happening, one of the challenges you're going to have is communication, prioritization, all that sort of stuff. Again, cut through the noise to get stuff done. So whatever that means for you in that context, and it's going to be different, it's going to be unique in your situation. But whatever it means for you, cut through the noise, maybe, ah, you've got to like dance around the game a little bit because you got to produce a doc or you got to go do the Jira tickets or whatever, but you still got to do that for a little while. But just cut through the noise and ship, cut through the noise and get the output, cut through the noise and have that impact. And again, sometimes you do have to play the game, but the goal is not to play the game. The goal is to do these things. Playing the game is a perfunctory thing that gets you over here. No specifics because each situation is different. But that's the point.

Speaker C: I love that. I think that's a fantastic place to wrap today's episode. Thank you all for listening and looking forward to being with you again in two weeks time.

Speaker B: Thank you for listening to Developing Leadership. Make sure you subscribe to follow us on our journey to more meaningful engineering leadership. If you have any challenges or topics you would like us to explore in an upcoming episode, tweet or DM US EVleadership developing leadership is powered by Athenian. We are introducing a winning approach to engineering metrics that can help you empower your teams to autonomously improve. If you want to learn more, go to athenian. Com. Thanks to Cofarition for consulting on and producing the podcast. See you in a couple of weeks for another episode of Developing Leadership.