The Manager of Managers
Episode 15: The Manager of Managers
===
Eddie Flaisler: [00:00:00] Hey everyone and welcome back to the PDD podcast. Today's question kind of made us go, huh, it's a thing, isn't it? It deals with the idiosyncrasies of being a manager of managers.
Eddie Flaisler: I don't think either Morgan or I can claim to have read every single book ever written on engineering management, nowhere close actually. But having quickly read through the table of contents with some of the classics to jog my memory, I can definitely say there's plenty on general people management practices, as well as strategy and execution for more senior leaders, but not a whole lot on what people management looks like when your reports are managers themselves.
Eddie Flaisler: Let's dig in and see if we can surface some useful frameworks for that today. I'll go ahead and read the question. Dear PDD, I am a senior director of engineering at a public company. Though my path to this role was a bit unconventional. Up until last year, I had always been an individual contributor. In my current company, I was a very senior engineer working closely with engineering leadership.
Eddie Flaisler: When one of my org heads left, I was [00:01:00] asked to step in and lead their team. Since our IC and management ladders are level equivalent, this transition made me a senior director. Now, I oversee a group where one manager has both ICs reporting into them and another manager under them with their own team.
Eddie Flaisler: That team is struggling, and I suspect the manager of managers isn't giving their frontline manager enough support. I'd like to coach them, but I'm not even sure what success looks like since I've never managed managers before. Any advice?
Morgan VanDerLeest: He might not have a lot of experience, but I like that even though he spent most of his career as an individual contributor, he does understand that there's more to managing managers than just saying, deal with it. It's your team. It's a good start.
Eddie Flaisler: A very good start. Cutie intro? Let's go.
Morgan VanDerLeest: I am Morgan.
Eddie Flaisler: And I am Eddie.
Morgan VanDerLeest: Eddie was my boss.
Eddie Flaisler: Yes.
Morgan VanDerLeest: And this is PDD: People Driven Development. You know, Eddie, we tend to talk a lot about defensible organizational design, specifically about having an org chart where you can justify the [00:02:00] number of people managers and high level engineers relative to the low and mid level ones who do most of the coding. Somehow that's the first thing that came to mind for me.
Morgan VanDerLeest: When you read that question, I don't think we have enough context to say whether the org structure they described is justified, but I'm definitely curious about the value each person in that management chain is expected to bring.
Eddie Flaisler: Yeah, I think you're absolutely right to be curious about this. In fact, I would argue that being able to clearly articulate this value you're talking about is the key to unlocking the root cause of the performance problem the person is describing. That is what will help our listener pinpoint what's missing and work with their report to develop a plan.
Morgan VanDerLeest: Always happy to be recognized for my owl instincts. Where do we begin?
Eddie Flaisler: Well, we should probably begin by giving some examples of what a frontline manager typically might not do, possibly because they lack experience, but definitely because they lack the bandwidth and circumstances. So we get a better sense of the gaps a manager of managers is filling. For example, a frontline manager might not rethink our [00:03:00] observability strategy and how to balance knowing before the customer with cost constraints, because week after week, they're directly impacted by a situation where their team couldn't locate data relevant to a problem report fast enough, not to mention they don't have the full picture of the organization's finances.
Eddie Flaisler: So they might just give the OK to go ahead and ingest the full log instead of filtering it first at the source to reduce size.
Morgan VanDerLeest: Oof, that hits too close to home.
Eddie Flaisler: Totally. They might also not be best positioned to make smart build versus buy decisions because they're the ones who need to look their engineers in the eyes and tell them they can't build this cool thing which will help with their promotion case because we're buying off the shelf instead. Not to mention they might be so deep already in the design conversations with their team that taking a step back to assess viability of the whole thing is difficult.
Morgan VanDerLeest: It is difficult, but makes sense.
Eddie Flaisler: They might alsoo not be able to distinguish between burnout and issues with hiring and onboarding because their team isn't large enough to spot a clear [00:04:00] pattern. Because if most people leave before a year, it typically suggests a hiring or onboarding problem. If they leave after a year, burnout is more likely. Another example where frontline managers have limited agency is with building partnerships in the company. These are important.
Morgan VanDerLeest: I would love to dig into that a little bit. Why would it be more difficult to build these partnerships if you're frontline?
Eddie Flaisler: I mean, we've mentioned that people need to build trust in order to work well together. But trust isn't built in a vacuum or in this artificial one on one you schedule with someone.
Eddie Flaisler: You need to get an opportunity to work with them and have a positive outcome. In reality, Frontline Engineering Managers are rarely exposed to more than their own peers in the same org and product or marketing partners, whereas people with broader scope typically get to work cross functionally a lot more.
Morgan VanDerLeest: I'm starting to get a good picture of the gaps here, but let's frame it as what the manager of managers brings instead of what gaps they fill. So it's easier for people to understand. So given everything you just said, what is the value we need from managers of managers?[00:05:00]
Eddie Flaisler: Well, unlike Frontline Managers, who are deep in the details of the work every day, all day, Managers of Managers have the advantages of autonomy on their time and bandwidth, Detachment from inter team dynamics, and of course, broader context. But these aren't just perks, they are given so these skip level leaders can proactively shape how their organization runs.
Eddie Flaisler: So, basically redesign the box rather than work within its constraints. If you look at it through this lens, the role of managers of managers at all levels, from a senior EM to SVP, is essentially the same. Maximize the value produced by every dollar spent on your organization.
Morgan VanDerLeest: Whoa, Eddie, let me stop you right there. You just casually mentioned that managers and managers have time and bandwidth, but I'm sorry, that's just not true. In my experience, the more senior the manager, the more they seem buried in meetings, reporting and cross functional drama. I think many would agree with that observation.
Eddie Flaisler: As would I. I do think we need to make a distinction between the method [00:06:00] and the goal and not rush to assume that meetings, reporting, and drama are the goal of the work, just because that's how many people in this position spend their time. You know, I read an article some time ago about how bureaucracies are created.
Eddie Flaisler: Bureaucracy exists in particularly every organization, including surprisingly small ones, and it can be minimized, but never fully eliminated. The processes that make up bureaucracy seem to always originate in this tactical solution to a specific problem that someone who is not even an authority figure had at some point.
Eddie Flaisler: And then these solutions just got copied and ingrained over and over until no one remembers why they exist. They just become how we do things. So then, when you join somewhere as a leader, no matter how senior, you join a system with some established ways of working. And it's so deeply ingrained in how the organization runs, that even if you're a C level executive, it seems like you're overstepping if you're questioning their effectiveness.
Eddie Flaisler: This is the story of every meeting and reporting heavy culture I know. And [00:07:00] I can't even tell you that I'm judging that. You know, we all try to solve for similar needs. We want to maintain a sense of control over a situation. We want to get lots of validation before making a decision that feels risky to our career.
Eddie Flaisler: We want to make sure people whose opinion we care about don't feel left out of a conversation that might deem important. So we just add more and more communication. In person and in writing. But that doesn't mean it's what we were hired to achieve.
Morgan VanDerLeest: You know, I don't want to call out. There's nothing inherently wrong with lots of meetings. I know we feel like there is, but the meetings themselves are not the problem. If the meetings are working and if that's a great way to communicate things and to gather information and be able to pass that around, perfect.
Morgan VanDerLeest: They're doing what they need to do. If meetings are getting in the way of work happening and communication is not happening and that information is not disseminated and brought up to the right people and shifted around, then that's a problem. I'd say it's probably less to do with the meetings themselves and more just about managing your calendar.
Morgan VanDerLeest: You do have a limited amount of time. So how do you leverage that best for your [00:08:00] organization?
Eddie Flaisler: I cannot agree more.
Morgan VanDerLeest: So Eddie, I'm hearing you on meetings and reporting, but if they take up all the bandwidth. We're still back at square one. You're the one who always talks about making friends with reality and measuring the value people bring under the constraints of the job, as opposed to by some theoretical rubric.
Morgan VanDerLeest: If everyone is expected to spend their time over communicating, there's not much room left for deep work.
Eddie Flaisler: Well, you're not wrong, but a big part of the heat that comes with engineering leadership is the backlash we faced when prioritizing our time and being able to navigate that is part of the maturity needed for these roles. Maturity as an adult, not as a manager,
Morgan VanDerLeest: I love the way you put that, say more.
Eddie Flaisler: the more senior leader you become. The more abstract your scope is, your mandate is much broader. You are responsible for open ended customer or business problems, as opposed to making sure that individual engineers are supported in doing their job well. When the definition of success is not people X, Y, Z are delivering and happily retained, [00:09:00] it's far less clear what you need to do to be successful.
Eddie Flaisler: And for better or worse, it means you have the freedom of deciding on the activities you spend your time in. There are no sprint rituals when you're a director.
Eddie Flaisler: There are practically zero situations where following up with your report every hour is helpful, or a good use of your time when you're a VP. The path to success isn't outlined for you, and that means you have to actively prioritize on two levels. One, how much time you dedicate to focused work and managerial individual contribution versus meetings and correspondence.
Eddie Flaisler: Two, what you actually do with that time you set aside for focused work. Now, two is an interesting exercise in engineering strategy, right? What are the most effective levers you can pull in a given situation for maximum benefits?
Eddie Flaisler: But the real challenge is number one, deciding how much time you dedicate to focus work. Sounds ridiculous, but do it wrong and your career in that workplace is destroyed.
Morgan VanDerLeest: It sounds dramatic, but probably accurate.
Eddie Flaisler: It does, doesn't it? One of [00:10:00] the most clever things I've heard at work is that as a manager your team isn't just the people who report to you. It's the entire company. It's true. You are a proxy for your team, and if your peers are higher ups, feel deprioritized or ignored because you're not accommodating enough to their ways of working, so you don't attend each one of their meetings or not always available to correspond, then that perception trickles down.
Eddie Flaisler: It lowers their motivation to collaborate with the teams under you. Knowing it ultimately benefits you. I won't lie, there were times when I felt my org needed so much attention that I was adamant about protecting my time, but that made some of my peers feel like I was undermining their work and I had to put in a real effort to fix that.
Eddie Flaisler: That said, years later, I don't regret some of the head down initiatives I took on. They turned out to be hugely valuable for the company's growth. So again, prioritizing is a big part of the work.
Morgan VanDerLeest: You know, I'm glad you called out perception there. Cause I think that's one of the most difficult things to get right. Really? It's almost any manager, just because you [00:11:00] don't know what other people are thinking at the end of the day, but as best you can, it's helping to make sure that the perception that you have of your team and the perception that others have is as close to accurate as possible.
Morgan VanDerLeest: Getting that reality to align and making sure that things aren't too far off both ways. If somebody is not doing well, you need to make sure that they can then realign with the perception and get better and vice versa. If they're doing great, other people need to know about that.
Eddie Flaisler: So true.
Morgan VanDerLeest: Now I want to start bringing us closer to our listeners question. They want to coach their manager or managers, but to do that, they should first diagnose the problem. So to enable diagnosis, what categories or criteria do you use to evaluate the work of a manager of managers? You've made it clear that proactiveness and keeping the order running smoothly is key.
Morgan VanDerLeest: And that a meeting heavy culture isn't an excuse, but how do you actually measure that proactiveness? Engineering orgs will always have problems. So how do you know if this person has done enough?
Eddie Flaisler: First of all, do me a favor. Let's call manager of managers by its acronyms MOM going [00:12:00] forward. It'll save me a lot of frustration.
Morgan VanDerLeest: It's going to kill me to say MOM the whole time.
Eddie Flaisler: I know. So to answer your question, like with every other employee, there's the what and there's the how. We'll start with the what. There are many high level trifectas people use to describe the expectations for managers. People, process, product, tech team trajectory, lead, leverage, learn.
Eddie Flaisler: I don't feel any of these is specific enough. The one I do like because it's closer to the work is clarity, alignment, and execution. I find this trifecta to be particularly relevant to MOMs. Why? Because frontline management is mostly about direct execution. So managing day to day operations and ensuring individuals have what they need to succeed.
Eddie Flaisler: As a MOM, your scope shifts, I can see you laughing, but I'm still going to call it a MOM. As a MOM, your scope shifts from direct execution to organizational effectiveness. Your job is no longer just about making sure work gets done. It's about ensuring the right work gets done across multiple teams in a [00:13:00] coordinated way.
Morgan VanDerLeest: You know, I bet we're going to get to some of this later, but I think in order for frontline managers to prepare themselves for becoming MOMs, - your acronym is going to wreck me - I think in order to prepare themselves for that, the best way to do so is to really make sure they have self organizing teams to get themselves to the point where they're almost managing their way out of a job.
Morgan VanDerLeest: Because if their team works well without them, Then they've managed really well. Now that can be kind of a tricky thing and people want to feel needed and that's a whole other issue to deal with and process, but by helping to get that trajectory moving there, that's going to help set frontline managers up well, for promotion, good reviews, et cetera,
Eddie Flaisler: I was definitely thinking of talking more about that in the how portion, but I have to say you're absolutely right. And in fact, when frontline managers used to ask me at work, how do I become a manager of managers? Assuming the opportunity presents itself, I would always say, Make yourself redundant. The more independent your team is, the better the job you're [00:14:00] doing.
Morgan VanDerLeest: Love that. Now let's break down the trifecta. Starting with clarity.
Eddie Flaisler: Okay, one thing I always emphasize is that the most important person for an employee is their direct manager. Not the skip level, not the executive leadership team, the direct manager. They are the employee's proxy to the company, no matter how small or large the company is. Of course, the executive team can definitely say and do things to break people's trust in the organization, so please don't.
Eddie Flaisler: But even if they're inspiring and do all the right things, if you as an employee don't appreciate your boss and believe they have a seat at the table and know exactly what it would take to set you up for success in the company at this point in time, you're walking attrition risk and chances are you're also giving mediocre performance at best.
Morgan VanDerLeest: Very true. I think when people sometimes talk about an EM setting up their team for success, they think about structure, resolving dependencies, developer productivity, but not so much about what the right things to focus on are in this current climate for maximum impact and work [00:15:00] visibility. Of course, if you're a bad manager, period, and your team doesn't trust that you have their best interest in mind none of what you know about what success looks like in the company matters.
Eddie Flaisler: Very true. But let's not jump the gun. We'll get to performance managing managers.
Morgan VanDerLeest: All right, go on.
Eddie Flaisler: So anyway, the point I made about your relationship with your direct manager applies here because it's a MOM's responsibility. Now you're making me laugh, but don't, don't record that. I know you will. So anyway, the point I made about your relationship with your direct manager applies here because it's a MOM's job to provide clarity to their managers so they in turn can show up, informed in front of their teams, and clarity isn't achieved through a weekly email or a brain dump in a staff meeting.
Eddie Flaisler: You have to work at it. It's a three step process. One, you make sure you understand what's important. Can you clearly explain how the mission and vision translate into your org's work? Do you understand what the business is prioritizing right now? Is it growth at all costs? [00:16:00] Is it profitable growth? Is it something else?
Eddie Flaisler: What's the most impactful lever to achieve that? Captured market size, network effect, growth margin. And the biggest thing Do you understand who your users are and what's important to them? That's lens zero for every decision. If you don't have a firm grasp, neither will your managers.
Eddie Flaisler: Two, repeat this context you have ad nauseum in every interaction with your managers. I once heard someone say that when you feel like you've repeated something way too many times, that's about when it starts sinking in for people. And three, which I find most important, provide frameworks for your managers to instill this understanding in their teams.
Eddie Flaisler: I don't know if you remember, Morgan, but remember that annual planning exercise we did at Lob? So instead of just telling teams what they'd be working on for that year, I wrote a step by step guide for them to create their own plans with you guys. In theory, they had the freedom to decide what to work on. In practice, that guide surfaced all the business goals and constraints, so the plans ended up [00:17:00] practically identical to what I would have dictated top down. Except this time, the team shared the ownership of the decision.
Morgan VanDerLeest: I really love that last point. I think it's a great example of providing good context to your teams so that then they can make better decisions. It's not about them just figuring everything out for themselves, but can you provide the context necessary for them to do well?
Morgan VanDerLeest: And that's a big deal. So, all right, clarity makes sense. But how do we measure that?
Eddie Flaisler: Well, I can tell you my techniques. It's far from being an exact science, but at least it provides some sense of how they're doing. The most important thing is to be transparent with your MOMs that this is what you'll be looking at.
Eddie Flaisler: Okay, so one is qualitative surveys asking the MOM's teams about their understanding of the mission and vision, about how the work ties to that, about the impact they think they're having, and in general, their belief that their manager is equipped to set them up for success in the company.
Morgan VanDerLeest: Not to take away from anything you're saying, but I don't need to tell you that oftentimes people feel A complete lack [00:18:00] of understanding of the business goals and how their work fits in, because often the executive team keeps changing direction, isn't very transparent and not because their skip level isn't doing a good job.
Eddie Flaisler: I don't disagree. I think this, again, is an example of why alignment across the leadership chain about what we're doing and why is so important. And also a reminder to consider circumstances when evaluating performance.
Eddie Flaisler: If you, as the manager of a MOM, have enough signal to tell you that they are communicating well, you don't have anecdotal evidence to the contrary and experience yourself the lack of clarity from above that the team is complaining about. Of course, you should not penalize your report for that.
Morgan VanDerLeest: Fair enough. Go on.
Eddie Flaisler: So, for two, I'm going to assume that a mom has at least two managers reporting into them. It's very rare in a, as they say, generative culture, to see a manager have just one manager reporting into them, unless they have something else going on, like in the case of our listener.
Eddie Flaisler: Anyhow, if your MOM has two or more managers reporting into them, you can check for messaging consistency. Are these [00:19:00] managers independently articulating the same priorities and focus areas without needing constant correction?
Morgan VanDerLeest: That makes sense. Anything else you want to touch on here?
Eddie Flaisler: Well, if people keep asking the same strategic questions in AMAs and all hands, it suggests a clarity gap.
Morgan VanDerLeest: It's situations like that, that I think are a great way to bring your management team together. So when you have your weekly, biweekly meetings or whatnot, if you're hearing a lot of those things, like discuss them as a group and make sure that you're able to go and then disperse that information.
Morgan VanDerLeest: Just like you mentioned earlier about needing to repeat things, maybe asking it once in the all hands and saying it even clearly and perfectly once, which rarely happens, i s not the right way to go about it or not enough of a way to go about it. You need to repeat, you know, follow up with individuals and make sure that they're actually getting what they need.
Morgan VanDerLeest: But that also, again, also applies on the manager level. If folks are not super clear and there's even just a little deviation, what they're saying, it's going to end up causing some discord may not be a big deal, but it could be, and that's a problem. So make sure that you're providing your [00:20:00] managers with the ability to, understand, ask questions, get aligned and run forward with the same
Morgan VanDerLeest: messaging.
Eddie Flaisler: Totally. And, you know, people also take information differently, so that flexibility in learning how to communicate messages is very important.
Morgan VanDerLeest: Yes. Relatedly, let's move on to alignment. I have a feeling of the difference between alignment and clarity is not super clear to people. Pun intended. Doesn't alignment just mean that everyone is clear on the same thing?
Eddie Flaisler: No. Alignment is its own thing, and I'll use a mnemonic for that.
Morgan VanDerLeest: Please not another cringy one like Eddie's dwarf waterfall.
Eddie Flaisler: First of all, I thought that one was great. See, you remember it. But anyhow, no. For this one, I want people to remember BGP. The Byzantine General Problem.
Morgan VanDerLeest: Ah, the distributed systems one, Byzantine fault.
Eddie Flaisler: Yes. The distributed systems one, the blockchain one. The idea is the same in the Byzantine general problem. Multiple generals must coordinate an attack on a city. They must attack at the same time to succeed. But since it's Byzantine times, they can't just hop on zoom.
Eddie Flaisler: So instead they rely on [00:21:00] messengers who may be delayed or lost or even compromised. The challenge is reaching consensus on when to attack. This is the core issue cryptocurrency had to solve. Because in a decentralized network, there is no central authority to verify transactions.
Eddie Flaisler: This is where consensus mechanisms like proof of work or proof of stake come into play to ensure all nodes agree on a single valid ledger. In management, it turns out to be no less complicated. If you're a MOM, your organization is focused on a mission and your managers are solving different pieces of it that need to fit together.
Eddie Flaisler: For you, it means a few things. It means making sure the software each team owns interfaces well with the others. It means making sure the delivery of the different teams is timed and coordinated. It means making sure they collaborate and support each other. That their agendas align with the overall mission.
Eddie Flaisler: That everyone gets updates simultaneously. And, of course, that there's a shared framework for decision making and prioritization. If you do not cover either of these [00:22:00] bases, you're not going to achieve what you're tasked with. Period.
Morgan VanDerLeest: And what does that look like concretely? What does a MOM do to achieve that?
Eddie Flaisler: Well, for one, you have to establish a healthy incentive system across the organization. The way you measure the success of your teams will determine whether or not they're aligned. I believe we mentioned misaligned incentive systems in previous episodes.
Morgan VanDerLeest: Yes, say more.
Eddie Flaisler: I've encountered engineering organizations where each team was assigned a distinct quantitative business metric to measure its effectiveness. Because those metrics represent somewhat disjoint results, they discourage collaboration and contribution to other teams.
Eddie Flaisler: Why would I help you with your agenda only to be told I'm not moving my own needle? So friction occurs regularly during dependency resolution and authority has to intervene.
Morgan VanDerLeest: Yea but that's easier said than done. At Lob, for example, we had several teams who worked on very distinct aspects of the product, even though they were just a frontline manager and a few engineers. It's not uncommon, but especially so for smaller startups.
Eddie Flaisler: It's not uncommon at all, but that's exactly where a MOM [00:23:00] should see that these metrics are assigned thoughtfully, and we don't just give up on nuance simply because we decided that every team should be measured differently. For example, a platform team like Infra or Data, who not only focuses on making their domain robust, but also have to support other teams can be assigned metrics like time to feature integration, time to process requests, pipeline uptime. These all impact the experience of the customer directly, but also make the product engineering teams far less frustrated.
Morgan VanDerLeest: And for the product engineering team, what's the nuance you're talking about?
Eddie Flaisler: Well, that entirely depends on the mandate level of the MOM's organization. If your org is supposed to just build something to spec, and it's just really complex or you need multiple teams working on it, then the only thing that really matters is the quality and velocity of output. Plus how well the non functional requirements are met.
Eddie Flaisler: Things like performance or security or reliability. You know, people love to say measure outcomes, not output. But in this case, the outcome is the output. The job is to [00:24:00] deliver the thing correctly and efficiently. Now, if the mandate is to solve an open ended customer or business problem, and each team is tackling it from a different angle, then sure, you still want to measure the impact of these specific pieces of work.
Eddie Flaisler: But you also need countervailing metrics to make sure teams don't operate in silos and forget they're part of a bigger system. That means looking at things like how many other teams are actually adopting the framework you're building, or how easy it is for them to integrate with it, how quickly dependencies get resolved, stuff like that.
Eddie Flaisler: And what's even more important than coming up with these metrics? is that when you assess how well the teams did on their metrics, you keep in mind that there's a trade off between the business metrics and the countervailing ones. So you don't expect to see both of them skyrocketing. In fact, if you do, the metrics are probably being gamed.
Morgan VanDerLeest: You know, one way that I love to look at a team's individual metrics and the countervailing metrics is going back to we're all people, especially as a manager of managers, you want your teams [00:25:00] and your managers helping each other out. You want that.
Morgan VanDerLeest: That is a thing to help enforce because they're people. If I help you, you will help me in the future, et cetera. It's the way that human relationships work. So even if you have distinct metrics and it doesn't seem like it's going to work, you know that you are part of a bigger team, part of a bigger company.
Morgan VanDerLeest: As you mentioned earlier, your team is the company. We need to be able to make trade offs like that, knowing that even if the thing that you're doing isn't selfishly impacting my metric right now. That it is doing a greater good for the company. And honestly, just communicating about that is probably all you need.
Morgan VanDerLeest: Hey, we took some time away from X metric to enable team Y with their ABC. There's nothing wrong with that. In fact, that's probably a super healthy thing that your leadership would love to hear, because that means that you as a manager, manager, and your leadership team is looking at the problems that your company needs to solve overall.
Morgan VanDerLeest: And that you made a priority decision around that. That's a good thing.
Eddie Flaisler: That's an excellent thing. That's what it means to be a team. That's why I always say, there is no team in I. Wait, it's, there's no I in team. Yeah, there is no I in team.
Morgan VanDerLeest: I feel like today [00:26:00] is just Eddie's day of making me feel incredibly uncomfortable while I'm going through this podcast. So I appreciate that. Thank you. All right. What else besides metrics to ensure alignment?
Eddie Flaisler: A culture of writing. There is absolutely no way around this, and if anyone ever tells you that you have "big corporate energy" because you're trying to introduce that, ignore them.
Eddie Flaisler: They're mostly protecting their expert position that we discussed in the systemic imposter syndrome episode. A culture of writing means a few things. One, API and integration guidelines. Talk about never too small for that. You know, I'm doing the backend for my product, Mission Control, while I have another developer doing the frontend.
Eddie Flaisler: He is so meticulous and very technical, and still we had to establish a framework for deciding and documenting the API between backend and frontend, because it was just a mess before that with lots of rework. So no, never too small.
Morgan VanDerLeest: I can't tell you the number of times, even just recently that I thought how important it is to have clear, well understood API, code base, just [00:27:00] general interaction and code writing guidelines. It makes such a foundational difference to the way things happen. It doesn't have to be perfect. They can be unique to your org and the way that things are done.
Morgan VanDerLeest: But what matters is that there is alignment around that, which that culture of writing helps so much
Morgan VanDerLeest: with.
Eddie Flaisler: The cumulative savings in time are insane.
Morgan VanDerLeest: So what's the next thing?
Eddie Flaisler: Two is transparent decision logs. We also talked about that in the past. If one or more of your teams are making decisions impacting others in one on one Slack messages, or even a public channel, but with so much noise and irrelevant context drowning it, then your purview is in trouble.
Eddie Flaisler: Instead, I really like Coda's two way write ups framework. It's like sending out an RFC for public comment, but a lot more interactive.
Morgan VanDerLeest: I feel like that also leads back to what you mentioned earlier about repeating yourself often. Those transparent decision logs are great at multiple levels and should be repeated and shared on a regular basis.
Morgan VanDerLeest: So the things that an individual manager says about their [00:28:00] team, the things that the manager of managers says about that and up to leadership, like there should be a lot of repetition within those and it makes everyone's job easier if you're able to borrow and share and repeat those things on a regular basis.
Morgan VanDerLeest: So definitely lean into that and the transparency makes that even easier.
Eddie Flaisler: 100%.
Morgan VanDerLeest: All right. What else?
Eddie Flaisler: So 3 is standardized release cadence and a no surprise policy. Everyone knows what goes at when. You know, there are a million tools that solve this problem. It's not about lacking technology. We just need to be disciplined enough to use them. Four is a good, easily manageable way to file issues between the teams.
Eddie Flaisler: Portal is great, pinging the on call or manager in the middle of them doing something else, not so much.
Morgan VanDerLeest: Also assessing that as the manager of the MOM is probably the easiest because you just see these things being done.
Eddie Flaisler: that's right.
Morgan VanDerLeest: I'll even lean a little meta into the culture of writing because the best way for you to process information is via writing it and getting things out of your head. And by developing that culture of writing in the first [00:29:00] place, it's going to help you, it's going to help your managers.
Morgan VanDerLeest: It's going to help your manager's reports. It's going to help everybody. The fact that you've processed, thought about a thing and then got it out into the world is a big deal. Leaning into that as a whole is going to be really life changing for an organization, to be honest.
Eddie Flaisler: Across All levels.
Morgan VanDerLeest: Any final thoughts on alignment?
Eddie Flaisler: Yes, operationalize a protocol for decision making in the team. There are plenty of ways to do it that are unnecessarily process heavy. And it also doesn't have to be this fabulous mathematical formula to ensure everyone's opinion is taken into account.
Eddie Flaisler: You just need to make sure everyone understands that once this protocol has been established, decisions made through it are authoritative. In terms of assessing the MOM on it, Same idea, you see it.
Morgan VanDerLeest: All right. Moving us along execution,
Eddie Flaisler: So execution is a very interesting one because depending on the person, it can be the easiest one to manage or the hardest one. It typically means sitting or standing at your desk, often with very partial information [00:30:00] because you're farther away from the production floor and you have to choose very carefully what questions to ask so you get the insights you need without overwhelming people or making them feel micromanaged.
Eddie Flaisler: And with that limited context, figuring out how to optimize the environment so your teams can execute smoothly and with minimal friction. I'll save you the question and start from how to measure that as the manager of MOM. For better or worse, execution should be assessed exclusively through business or operational goals and metrics assigned to the group.
Eddie Flaisler: Do you remember how we defined the role of a mom at the beginning? Shape how the work runs. That means whatever it takes within the bounds of the employee handbook and our organizational rules, principles, and associated behaviors. And if that's how I define the role, I have to measure outcomes. Any other way would be inherently biased, with some exceptions.
Morgan VanDerLeest: Which I can definitely think about. When you manage someone, you see their work. So you also see them sometimes doing or not doing something that will very clearly negatively impact their organization's [00:31:00] performance. Like not performance managing an engineering manager who's doing poorly. A second example I can think of is when you see that your MOM's framework for gathering input from the teams is needlessly overburdening.
Eddie Flaisler: I'm feeling very cold out here, but I have to agree. When keeping you in the loop is keeping your managers from doing other things, you are not running the show effectively. You know, a few weeks ago I read an interview with Charity Majors where she said a dashboard should be able to answer questions, otherwise it's useless.
Eddie Flaisler: That made me think of all the times I've sat in front of a super rich dashboard full of live graphs, feeling this crippling anxiety because I had all this information in my fingertips. But none of it made any sense to me. And as an engineering executive, I'm supposed to be this technical authority, so I felt too awkward to ask.
Eddie Flaisler: You see the same issue during incidents. A MOM needs to stay informed so they can keep their leadership and stakeholders updated. But if there's no efficient way to get that information from the team actively working on the incident, the firefighters end up spending more time explaining what's [00:32:00] happening than actually solving the problem.
Eddie Flaisler: The issue is that at least up until recently, there was not a lot of technology out there that does this well, especially not cheap one. So while I definitely agree on the importance of this, there are always the constraints of what the budget allows. No question that this is a great investment.
Morgan VanDerLeest: The thing that's calls to mind for me is signal versus noise. We're all human. Your brain can only deal with so much, the less you have to focus on, the more aligned you're going to be able to be. And the better understanding your managers and teams are going to have about what they should be working on and why.
Morgan VanDerLeest: Lean into simplifying that as much as you can. Yes, at a business level, there's a lot of things to think about. A lot of things to worry about. A lot of data coming in. What is most important? Prioritize those things.
Morgan VanDerLeest: So going back to what actual execution related work looks like for the MOM. Do you have some thoughts there?
Eddie Flaisler: This one I'm very hesitant to answer because as I mentioned earlier, every situation requires different things. I can say that some typical output I see from MOMs who have [00:33:00] strong outcomes are things like 30, 60, 90 day plans for their managers or a good framework for EM performance management, like you mentioned.
Eddie Flaisler: Budget aware technical guidelines, risk analysis on the software they own, meaning they study questions that help them make decisions, like how big is the oncall rotation, or what is the lead time to fix an issue? Does it have any factors of extreme complexity, like challenges running locally or lack of logical coupling?
Eddie Flaisler: And I've also seen some moms use that extra time and bandwidth I was talking about to help their team with some needed research, like estimating worst case CPU memory and latency spike in unpredictable workloads. That was a very fun use case of Chebyshev's inequality, who said that stuff they teach you in college is redundant.
Morgan VanDerLeest: You'll have to explain that one to me offline. For those of us that didn't go to college for this. All right, Eddie, we covered a bunch of things already in terms of the what of managing managers. And I definitely think it gives our listener a lot to think about and helps narrow down the problem. This would probably be a good time to switch to the how of [00:34:00] managing managers.
Eddie Flaisler: I agree. How would you like to approach that?
Morgan VanDerLeest: I think the baseline here is to remember that a manager of managers is first and foremost, a people manager. The reports are managers and not IC, but they're still people. That means a few things still need to be maintained when compared to managing ICs and probably even more so because you're setting that example for their EM. I can think of a few things there.
Eddie Flaisler: Go for it.
Morgan VanDerLeest: Psychological safety first. Okay. We've defined and redefined that in the past, so I'll skip the nitty gritty details, but the idea is that not only is it important for the EM reporting into them to thrive professionally, but also these things tend to trickle down very quickly. If an EM reporting to a toxic MOM feels emotionally unsafe at work because of their boss, they have little to no capacity left to support their team through their challenges, not to mention shield them from the noise that can impact their work.
Morgan VanDerLeest: Imagine you as an EM know of some scary conversations going on around budget cuts. Nothing concrete so far, but still stressful and worrisome. Would it be easier for you to maintain [00:35:00] business as usual with your team? If your own boss is composed about it and mindful of the impact on you as well. Or if they're freaking out and taking it out on you.
Eddie Flaisler: Could not agree more. And I think that on the topic of emotional safety, there is also a particular behavioral anti pattern which is very specific to managing managers and one should be mindful of. I'm talking about managing through.
Morgan VanDerLeest: Well, managing through the manager of manager's version of micromanaging.
Eddie Flaisler: Yes, you see, there's nothing wrong with a MOM wanting the full picture of what's going on.
Eddie Flaisler: If anything, that makes them more effective in supporting their teams. The real question is where do you draw the line? And that's something you need to be thoughtful about because crossing it does something far worse than just upsetting the EM you're managing. It shatters their team's trust in them.
Eddie Flaisler: Your actions send the implicit message that their boss has no authority, doesn't know what needs to be done, and that if you actually want to get anything done, you have to go around them. You just stripped them of their agency. And then you're surprised when the team acts like they don't have a manager.[00:36:00]
Eddie Flaisler: Well, they don't. Because without realizing it, they now see you as their manager, except you don't have the bandwidth for them. It's a lose lose.
Morgan VanDerLeest: Can you give a concrete example of managing through?
Eddie Flaisler: The most straightforward one would be asking the engineers to work on things without going through their assigned EM. A less obvious one, but also deeply problematic, is when team members of one of your EMs escalate something to you without going to their manager first.
Eddie Flaisler: You might just want to be helpful so you address the request directly, but by doing that, you've just created a bypass and undermined the EM's authority. More importantly, you didn't stop to ask why they didn't go to their manager in the first place. Is there an issue? Is there a lack of trust? Is there a misalignment?
Eddie Flaisler: The only correct response here is, "have you spoken to your manager about this? They have full authority to address the issue." And if the person hesitates or waivers, dig deeper. Because that's where you might uncover a real problem that needs your attention. I have a friend who leads engineering for a startup, And in his [00:37:00] skip level one on ones, he always makes sure to ask the engineers how he can help.
Eddie Flaisler: Sounds almost obvious, but he also pays careful attention to any input from them that never surfaced when he talked to their EMs.
Morgan VanDerLeest: Something that I do want to call out is if you say that they have full authority to address it, but they don't actually have full authority to address it. That's a problem. So make sure that your managers are actually empowered to do the thing that you're suggesting they're able to do.
Eddie Flaisler: I stand corrected, absolutely.
Morgan VanDerLeest: Do you have one last example of managing through?
Eddie Flaisler: This one is a bit triggering for me because I was on the receiving end of it, but it needs to be called out. Whether it comes from malicious intent or just avoidance of hard conversation, the outcome is the same. Trust gets shattered. I had an engineering manager once ask me for more headcount. I had the budget and reached out to my boss for final approval, but they refused, citing C level guidance.
Eddie Flaisler: So I went back to the EM, explained that it was impossible, and assured them we understood the need and we were working on it. They were still frustrated, [00:38:00] understandably, and set up time with my boss. Now here's the plot twist. My manager could have said, you know what, Eddie told me about this, but now that I hear the pain directly from you, I've given it more thought and let's reconsider.
Eddie Flaisler: That would have been still frustrating for me, sure, but at least in alignment with the chain of command. Instead, they said, wow, Eddie never mentioned that to me. I'm just going to stop here and let the damage that did to my relationship with the EM sink in.
Morgan VanDerLeest: If I had a more appropriate drink, I would pour one out for that. Now I will say, Eddie, that out of all the bosses I've had, even one of the bigger proponents of manager managers being in the details. And let's be honest, when someone is trying to be close to the ground, it might just undermine the EM.
Morgan VanDerLeest: Where do you draw the line that you're talking about?
Eddie Flaisler: I don't think there's a universal definition. What I do know for a fact is that every manager front line MOM or senior executive needs to decide when they enter a role, what level of information they need in order to do their job well, and what specific red [00:39:00] flags justify digging deeper, even if it might seem excessive to their reports.
Eddie Flaisler: And then they need to stick to those guidelines, because consistency in management is everything. In an ideal world, I love the idea of manager READMEs. Where an incoming leader lays out their work style up front, so there are no surprises or assumptions of negative intent when they do something. But I get that not everyone is always comfortable with writing that, present company included. A lot depends on the climate and the culture you're stepping into. That said, at the very least, you need internal clarity on the information you require and what you consider a red flag. As long as you apply that consistently across your teams, people won't be reading too much into it for long.
Morgan VanDerLeest: Ooh, I feel like the red flags part is worth digging more into. Do you have an example of that?
Eddie Flaisler: Yes, in one of my roles, I inherited a team where the manager was an experienced leader, well respected and loved by their team. The team was delivering overall and my instinct is always that if it works, don't fix it. But one thing kept bothering me. I could never understand what [00:40:00] individuals in that team were actually doing.
Eddie Flaisler: I'm not talking about some DOGE style, your five achievements this week level of detail, but enough to get a sense of individual contributions, especially since the manager considered everyone promotion worthy, everyone were exceeding expectations, and everyone were leading the charge. Whenever I tried to dig deeper, I got vague responses at best, and at some point, even outright aggressive defensiveness.
Eddie Flaisler: Then January hit. Which meant decisions on comp changes, retention bonuses, and even potential headcount reductions. I still couldn't get any real collaboration from the manager when assessing individuals.
Eddie Flaisler: So I did something that most EMs would see as a huge red flag from their boss. I went into the code myself and ran analytics on every single team member. The results were devastating. Two people were carrying the entire team on their back while the rest had two medium sized commits in three months. And before you ask, know these weren't deep strategic tasks requiring weeks of [00:41:00] design.
Eddie Flaisler: What happened next is out of scope for this episode, but the takeaway is this. Sometimes, even when a team as a whole is delivering, there are real performance issues underneath, and you have no choice but to look. Of course, this kind of deep dive shouldn't be your first instinct, but picking your battles wisely is key.
Morgan VanDerLeest: That's a great point. Some particular tactics that I've used in the past to try to help with this. One is having at least a rough summary, a couple of sentences per IC that ends up reporting up into me. I want to know roughly how they're doing, roughly what their growth path is going to look like, and what are any particular issues that they might have.
Morgan VanDerLeest: And I want to see how that shifts over time. That helps me just to have a very high level understanding of how folks are doing and to know that this manager is aware of how their team is doing on an individual level, what's going on. Those things don't always tie up to everyone's going to have the same coding contributions all the time.
Morgan VanDerLeest: That's fine, but you should have some kind of measurement outside of that, whether it's, you know, architectural design docs or whatever your organization uses, they should have some kind of a [00:42:00] footprint. You may decide what that metric is on an individual basis, but they should have some kind of a footprint.
Morgan VanDerLeest: I also find it incredible how issues with autonomy and micromanagement surface at all levels, including at those we typically associate with a lot of power.
Eddie Flaisler: Yeah, because it's just a human thing. And I think we sometimes underestimate the business consequences of not giving a leader sufficient autonomy. It's not just about low trust. And it's not just about the person doing the micromanaging, spending their time on that instead of what they should be doing.
Eddie Flaisler: The main issue with lack of autonomy is that it triggers in practically a hundred percent of people. Coping mechanisms like demand avoidance, so they refuse tasks and actually create these elaborate strategies to escape them. Or loss of intrinsic motivation to collaborate, which means they end up engaging more in self directed tasks.
Eddie Flaisler: The ego takes its power back. There's no way around it. And that's the main reason why micromanagement, unless very sparsely and carefully executed, is usually a one way street [00:43:00] in jobs. No turning back. People need to remember, especially when it comes to management of managers, where you are accountable for a lot more but have far less levers to make the thing run like you want, than if you are a frontline manager or even an engineer, that the EM reporting into you isn't you.
Eddie Flaisler: They will manage differently. So align on outcomes, align on principles, and deal with it otherwise.
Morgan VanDerLeest: So we talked about psychological safety and about justified and non justified micromanagement when managing managers. Is there anything else that comes to mind in terms of the how for MOMs?
Eddie Flaisler: I'll add two last things. Succession planning and using your power for good. We talked about succession planning or succession management in IC management. Basically making sure that if one of your engineers leaves tomorrow, the business isn't doomed. I think having contingency plans for when your EMs leave is also very important. So important that I'm not even sure if it falls in the what or the how bucket. The point is this, a [00:44:00] manager is a multiplier or a divider. It's not a cliche. As the hiring manager for that vacant EM role, you want to be able to afford to be picky until you find the right candidate.
Eddie Flaisler: To do that, you cannot have an organization where all hell breaks loose once an EM leaves. As it is, it's always a morale hit to the team when a leader leaves and there's literally nothing you can do about it. So at least show good business continuity. With managers, succession planning isn't necessarily about knowledge sharing or ease of onboarding into new code. It's more about two things. One, developing self managing teams, which is exactly what you mentioned.
Eddie Flaisler: And in self management teams, the structure of how things are done is so strong that they can deal with limited hand holding for a while. Two, is identifying and growing your next generation of leaders. You know, less so with executives, but when a senior manager or director is replaced in a company, and they go straight to hiring externally, I always ask questions.
Eddie Flaisler: Do we truly not have the talent bench in [00:45:00] place? Are people not motivated to do the job? Or are we just the type of management team who doesn't believe in growing people and assume that what they came to the job with, in our view, is all they will ever bring to the table.
Morgan VanDerLeest: That was one of my kind of barometers of success in the past was that if, as a frontline manager, if I'm going on vacation soon, or going on PTO, or even just going on like a short notice PTO, I have to do something quickly, you know, medical leave, whatnot. How often did I need somebody else to cover for me in those instances?
Morgan VanDerLeest: Sometimes, yes, big projects, something's going on where you really need that. But if most of the time I could step away a couple of days or a week and not have anyone stepping in for me as a manager, that meant I was doing a good job managing because my team was able to self manage when I was not there. You want to look for the same kind of thing in your managers when they have to step out, are you having to step in for them a lot? Not necessarily a bad thing, but again, I would say that's a relative barometer of success. How much are you having to step in for your managers if they're [00:46:00] not around for a handful of days?
Eddie Flaisler: Absolutely.
Morgan VanDerLeest: Now, one thing that you mentioned was using your power for good. What's that about?
Eddie Flaisler: Well, you know, Morgan, if you manage managers, you're by definition higher up in the leadership chain. I mean, if you still don't have a say despite your position, Run as fast as you can. But if you do have a say, it means you get to push back on decisions that do not align well with the health of your organization or the business goals you guys are accountable for.
Eddie Flaisler: Use that. If you made it to a senior position and still all you do is say yes to your superiors, that's a missed opportunity for everyone, including your superiors and the business.
Morgan VanDerLeest: Can you offer a concrete example here as well?
Eddie Flaisler: Yes, for example, the topic of technical debt is very prevalent in tech companies, and a common issue engineering leaders often have to deal with is the perception of any work that the customer can't see with their eyes as tech debt and a waste of engineering time.
Eddie Flaisler: So let's think for a moment about this business case. You work for a cloud SaaS company [00:47:00] developing a web application. The API between backend and frontend used to be a REST API.
Eddie Flaisler: Nothing wrong with that. It wasn't quick and dirty at the time and actually well thought through. All was good. But over time, the product started offering things that require a lot more data to be transferred quickly from backend to frontend. Now the API, even though configured optimally, is struggling to load stuff fast.
Eddie Flaisler: And of course it does. REST isn't for heavy workloads. So engineering wants to migrate to something like Connect RPC. It's quite a feat, and because of that, the non necessarily technical C level leadership is very worried. We don't have time to replace the whole thing.
Eddie Flaisler: Customers will be disappointed. We're not shipping any update. This is where I expect a MOM level leader to say, No, actually replacing the entire API to provide an exquisite customer experience in terms of performance is a big deal.
Eddie Flaisler: We will do it and let me work with the marketing team on language to explain why it's a big deal, even though they can only feel [00:48:00] it and not see it. That's what I mean.
Morgan VanDerLeest: That makes a lot of sense. I actually have a good example here as well. So One of my organizations, we were talking about how to utilize just metrics across the engineering org. What do we look at? How do we look at them? What's the use case, et cetera. Now there was a line of thinking that's like, well, obviously we just look at the metrics of individual people, dump it into a sheet and just compare, look at, go from there. Didn't feel right.
Morgan VanDerLeest: And we were really thinking about what are we trying to solve here? What is the point of utilizing this? Is there a one, one type fits all engineer that by looking at these metrics, we're going to be able to look at everyone in the same way? No. What is the like foundational unit of work at a company? The team.
Morgan VanDerLeest: So instead of, Hey, let's do the easy thing and just look at what are the individual metrics for folks and just compare and who's good and who's not in that way. Again, we've talked about this before, not a good thing. Let's look at team health. What does that look like? What are the things that we can actually assess how the team is doing work. Now, it's interesting because we actually were trying out some tools for [00:49:00] this, but then at the end of the day, we just fell back on JIRA and cycle time. Don't compare between teams. Just what's the cycle time of how long it takes between starting to write the code and getting it in production.
Morgan VanDerLeest: You've got coding time. You've got review time. You've got acceptance time, all valuable things. You can tweak all of those and those all impacted various parts of the team and organization. And that ended up being a really useful way to look at how healthy is his team? How is the team doing? And are we seeing changes in this cycle time over time?
Eddie Flaisler: One hundred percent.
Morgan VanDerLeest: All right, Eddie, a lot of ground as usual today. Any final thoughts?
Eddie Flaisler: Just one thought I've been holding on to since reading our listeners question about the manager who manages both ICs and another manager. It's not categorically bad. I've been in org structures like this one before and it was fine. But it reminded me that when designing a management chain, it's important to ensure you're not creating inherent conflict of interest. I've dealt with a case where a manager was given their peer's team, along with their peer, to report into them, while still managing their original ICs, people [00:50:00] this person had very close relationships with.
Eddie Flaisler: When performance review season came around, this new MOM allocated most of the budget to their ICs and only a fraction to the newly inherited team. Out of sight, out of mind. The full case analysis is far more nuanced, but the key takeaway is that when you reorganize, you're moving people, not just boxes on a chart.
Eddie Flaisler: And the structural decisions you make impact real working relationships, they impact trust dynamics, they impact fairness in career progression. So, something to think about.
Morgan VanDerLeest: I think that's a great point to end on and to the listeners, if you enjoyed this, don't forget to share and subscribe on your podcast player of choice. We'd love to hear your feedback. Did anything resonate with you or more importantly, did we get anything completely wrong? Let us know, share your thoughts on today's conversation to people driven development, that's one word, peopledrivendevelopment@gmail.Com, or you can find us on X or Twitter @pddpod. Bye everyone.
Eddie Flaisler: See you around!
Creators and Guests


