Why is the transition from IC Engineer to Manager so tricky (and how to get it right)? — Marcel Weekes, VP of Product Engineering at Figma

Brett: So appreciate you joining us.

Marcel: Thank you. It's really a pleasure to be here and I'm glad I got the invite.

Brett: So one place that I thought we could kind of jump off, um, in terms of our conversation is the topic of developing engineering managers and specifically how you think about taking IC engineers and helping them grow into great managers and leaders. And kind of maybe the, the specific question is, what do you think most people get wrong or where are the missteps when companies start to think about developing individual contributor engineers into engineering managers for the first time?

Marcel: Well, I think this is a real difficult transition, generally speaking. Um, it's fraught because. Typically, organizations are doing this under some level of intensity and stress, and at smaller organizations in particular, they're not necessarily doing it with a support structure in place. Um, so the, the challenge that I typically see is, the way this plays out is that someone who's an IC on a high performing team will be asked to be the manager of that team because it's growing really quickly and the team needs additional support.

So they'll go from being like a high contributor on the team on Friday to being a manager of four or five people on Monday and without much of a structure or supports around that. It can be really kind of a bumpy transition and people find themselves doing a new job that they haven't been trained for, don't necessarily have the skills for, and now the team starts to fall behind a little bit and that's when you get.

Folks falling into sort of the new manager death spiral as I call it, where the team starts to fall behind. And the manager who had been one of the highest performing folks on the team jumps in in order to help unblock the team. And they think that by writing code they can help the team get out of a sort of a bit of a ditch. And at this point now you're, you're back in the same situation you were before where the team doesn't have a full-time manager and that person is stretched really thin because they think they're in part trying to be a manager, but also in part trying to be an individual contributor. And they're not doing either one really well.

Um, and I think this is exacerbated for engineering teams in particular because with your typical p d or product design and engineering team, the bulk of the staffing is on the engineering front. So person, team, there's typically the single functional leader for PD and e. But then the bulk of the people on the team report into engineering.

So you've kind of got this situation where most first time managers and other functions might move into supporting one or two or three people initially. But for engineering managers, the first time they make this transition, they're often jumping into a team that's 5, 6, 8 people and all of the techniques that you need to support a diverse group of people like that.

You'll have some people who are senior, some people who are junior, some people who are long tenured, some people are new to the team. techniques are best learned through experience. Um, and new managers don't often have role models to pull from in order to gain that experience the most efficient way.

One of the things I think is really important in terms of leveraging experience is I want to leverage the experience of other people so that I don't have to make those same mistakes. And as a mentor, I want people to leverage the mistakes I've made in the past, so they're not making them. And that's like the super accelerant to someone's evolution as a manager is actually learning from other people, other managers.

Um, but if you don't have that structure in place, you're just asking people to make every mistake themselves for the first time. And at that point, it can feel really lonely as a manager because if you don't have a, a peer cohort, a group of people you can rely on or mentors, it is sort of a challenging series of mistakes that you're probably gonna encounter.

Um, and that, that's just, I think, unnecessarily difficult for folks.

Brett: Let's say we have. Have a team of five or seven engineers and they're at a size that it logically makes sense for them to have a manager. We can come back to the topic of exceptionally flat organizations and whether that always doesn't work in some of those topics. Um, how do you think about if nobody has ENG management experience or management experience, how would you go about figuring out if there was someone in the team that could grow into a really exceptional engineering manager?

Marcel: This is a great question because it comes down in part to evaluating talent, but also helping to evaluate motivations. Uh, these are often latent motivations. Like what, what's, what's driving someone and just asking. Asking a series of questions can really help. Um, Both the person you're asking as well as the person doing the evaluation. One of the things that I try and remind everyone is that leadership takes different forms, and oftentimes someone can be a leader as an engineering manager, or they can be a leader as a technical lead on a team. But when it comes to figuring out what is it that really motivates this person and gives them energy, this sounds somewhat reductionist because it's a blanket statement, even though everyone is their own special snowflake. But if you can determine that someone is really motivated by solving people problems as opposed to solving technical problems, then that's probably a decent candidate for getting into engineering management. Because engineering management is a subset of general management, which ultimately comes down to how you interact and motivate people. again, that's very reduc because you have people who are different points in their career. They have different sort of, Different team dynamics as to whether they are maybe the more tenured person on the team and whether they really have already sort of built up the trust of those around them and maybe a defo leader.

And then just need to be sort of, have that reflected back to them so that they can step into that position feeling comfortable. Because there is going to be a level of of imposter syndrome for whoever makes this transition. But you want this person to get energy from the work that they're going to be doing.

And if someone gets the most energy from solving really thorny technical problems, you wanna guide them in that direction and support them in doing that. But if someone gets the most energy from solving people problems or helping a group of people do something they couldn't have done separately, then that's someone who has some of the motivation for. also remind people it is not necessarily a promotion to go from being an IC to being a manager. Those are different and dual tracks. And it's important that as people make that transition or think about it, that they recognize being, I consider engineering management a service oriented profession. Um, and you really have to get into that mindset of you are there to provide a service to the people on the team, and you work for them.

They don't work for you. So people who already exhibit some of those behaviors are prime candidates for it. That said, it's still really important that you have a very candid and open conversation with them about some of the challenges that are likely and also some of the things they're giving up. Um, you know, one of the things that a lot of first time managers talk to me about is losing control of their own calendar.

Uh, oftentimes as an ic you've got a couple meetings a day and you can sort of. Put in blocks of time where you get to do heads down coding and doing the work that you really enjoy doing. But as a manager, you're very much more interrupt driven and other people set a lot of things on your calendar. And meetings are sort of the, the currency of the realm.

You spend a lot of time as an information broker, getting information, disseminating information, making decisions, and that happens in meetings. And meetings are your, your day all of a sudden is run by a calendar as, as opposed to like a list of poll requests or feature tickets. And, um, it's important that people understand what type of transition comes with going from IC to em.

Brett: If you were having lunch with an IC engineer, let's say they have eight years of experience on your team and you're trying to do your own analysis and pull on threads to build your own view as to whether you think this person could be really exceptional, what are the types of questions that you would ask them?

Marcel: So if it's someone who's got that level of experience, um, at this point they've probably had some level of interaction with maybe a summer intern or with a new college grad who's been hired onto the team. And that's usually a good spot to ask how that experience went, what did they enjoy about it, um, what did they not enjoy about it, and what would they do differently the next time they have one? And one of the things I'm trying to assess out there is the level of reflection that that engineer has as to their role in helping to onboard someone or up level someone. And. you get someone who's fairly, fairly reflective about their contributions and their role in the process, then you get someone who I think is maybe showing some of the subconscious signs of wanting to do this again and wanting to be a part of this.

Maybe at scale. Uh, if you get someone who's sort of like focused on the frustrations primarily, um, and doesn't really take accountability in terms of what they could do differently or maybe didn't learn from it or didn't feel rewarded from the process, then you, you try to find other areas to probe and ask around, but that's probably not an initial, um, initial sign that that's something they want to do.

Brett: Do you think a mediocre engineer can be a world class top 1% engineering manager?

Marcel: This is a really funny. Because if you ask world class 1% engineering managers where they would've ranked themselves as an engineer, they'll all almost universally say, oh, that was a pretty good engineer, but I wasn't great. But you hear that every time, right? And some of that's humility. I actually think a big chunk of that is your world class.

Top 1% engineering managers attract really, really good engineers and they retain them. So the population of engineers they work with is already really good and they're ranking themselves against that. Um, that's a long-winded answer to when I could have been more brief. I would say I do think you need to be a very good engineer, but you also need to be very good at reading people and having a high emotional IQ in order to really be effective with an engineering manager and then as, as a leader beyond that, um, So I, I think it's helps a lot if you can, especially in that early transition, if you are leveraging the skillsets you already have in place as a high performing engineer.

This is why I think it's really helpful for people to make this transition at a company where they already have a level of subject matter expertise on the technical side, and their learning muscle can be applied towards the engineering management skills as opposed to skills they already have in terms of learning about a tech stack or something.

Um, and then once they've done that, they can transition in their, these management skills they've learned are portable and they can take them with them to new companies and new organizations.

Brett: Peter Teals sort of famously had this idea, and I think Keith Rabois still believes very strongly in it, which is you take your best engineer and that is your engineering manager of the team. And my guess is hearing you talk broadly, you have issues sort of with that frame and you've seen it lead to bad outcomes.

But I'd be curious, maybe could you steel man it and make the case or explain why, maybe there's some merit to that idea, and then maybe kind of loop back on some of the ideas that you shared as to why that's potentially a trap or some of the issues you've seen with that line of thinking in the past.

Marcel: Yeah, it's a, I'd say it's a even more popular line of thinking than just with, with your typical vc. Um, and I suspect it's driven by some of the pragmatism around it and the immediacy of. Being able to hold a high technical bar for the rest of the team and effectively short circuit technical decisions that the rest of the team may be making.

So to get to the right answer as quickly as possible and point the team in that direction, I think there's, there, there's merit to that for sure. However, I actually think you could do a lot of that in a capacity that wasn't necessarily an engineering manager. Um, and that's part of the reason that I think that engineering managers should focus on being able to support the entire team, provide levels of autonomy for the team, and also create a dynamic where everyone on the team feels they can be a leader in some way and contribute to technical decisions and pointing the team in the right direction.

I think some of this maybe comes down to the timeframe that people are considering. If you're, oftentimes you're at a startup and there's a runway and you're talking about 12 months max. You, you don't have time for longer decisions or decisions to be reviewed. You wanna make the right technical decision as quickly as possible and keep the team moving.

And that's where I think people look at their best engineer to make those decisions. And if decision making is concentrated at the engineering manager level, then putting that person in that position makes sense. Um, I guess my counterpoint to that would be that I don't think decision ma making needs to be concentrated at the engineering manager level.

I think that's a bottleneck. And I think what you wanna do is have that person setting up the frameworks and processes and an environment in which people can make decisions as close to the problem as possible. And in that case, you'll have engineers across the board making decisions. No, that doesn't mean they're without review.

Um, but that same high performing engineering leader on the team who isn't an engineering manager, can be providing that review and technical reviews or through specs. And chances are though, probably be a bit more. Engaged and happy in that role if they aren't dealing with some of the things that they consider, um, using danger quotes here, overhead or the people manager tax.

Um, you know, one of the things that I think we don't pay enough attention to is the, as an industry is the percentage of high performing engineers who move into engineering management, do it for some period of time, leave that and never go back. And if, if that was like a failure rate of a service or something, we would do a postmortem on it and be concerned that the failure rate was so high.

Um, but in this case we just sort of say like, ah, engineering management wasn't for them. And we don't sort of like dig in a little bit further and say like, why not this person was effective? They chose to do it or was asked to do it. Uh, and then they decided they don't wanna do that anymore. And in part I think it's because we don't necessarily set expectations about what that job looks like or there're parts of it that aren't fun that we really concentrate there as opposed to spreading across the team.

Um, So I, one of my overall goals is for, us as an industry to better support people who are making that transition and to have a higher success rate with people making that transition and sticking with it because the industry needs good engineering managers,

Brett: What do you think the success rate is today based on your sample size at least,

Marcel: I'd say it's below 50%. and I think that's, that's, that's probably, it probably varies by company and stage of company, but broadly speaking, I'd say my experience below 50%.

Brett: and I think you started to get at this, but how would you articulate the root cause and how much of it is someone choosing to get into the role when they actually don't get energy from the things that you talked about? Maybe versus something like skills and capabilities that maybe intellectually they actually feel like they would get energy from developing people and being responsible for the results of a broader team versus building products themselves.

but I kind of, there's probably a few other reasons that you've noticed as well, but I, I think part of it is desire and the other part is capability, and I'm sure there's a few others, but curious how you think about that.

Marcel: That's a good question. I think you know, every failure or. Transition is, is different. Um, there is a class of people who get into it for the wrong reason. And whether that's, and that may not be on them, it may be the structure they operate within. In order to get a pay increase or to be recognized and valued by the company, they need to be on the management track.

And I, I would stipulate that that itself is a problem. Instead, again, the parallel tracks we're talking about should reward people at each step on either track. Um, but ultimately management's a hard job and it's not without challenge. So if you get into it for the wrong reasons and you're not motivated to do it, the difficulty of the job will cause you to sort of reframe, reset and maybe self

who into. And when we all first get into it, we lack some of the skills. It's often the case that there are skill gaps to being an effective manager. I think our, whatever your introductory manager level is at an organization is probably your most broad level because it supports someone who's doing this for the first time, maybe has three or four reports, as well as someone who might be two years into their management journey.

And you ask them to support 10 people. And those are two very different organizations. Um, but those people who step into those roles and maybe have skill gaps, that's where they're looking for the organization to provide some level of support, some level of learning and development. And this doesn't need to be like, I work at a 60,000 person company and they have a special learning and development program, and that's the only way I can learn management.

When I, when I refer to support and making that transition, it's literally having a mentor or a manager. Who can talk to you about, okay, this is the first time you're gonna have a difficult performance conversation. Here's the way to approach it. Literally just having that conversation with someone who's done it before makes you at least 10 times more effective the first time you do it.

And little bit, I mean, that's a difficult conversation. Makes a little bit more comfortable going into it. And if you find that people are operating at that edge of, they're starting to be comfortable in discomforting situations, but they're learning from that, that is a growth mindset and a growth opportunity for everyone involved.

But if you find that in, you know, without the right support structure, that same set of circumstances can put someone into a stressful situation every week. And that is a, that is a recipe for someone sort of self-selecting out that is not necessarily learning or operating at the edge of your experience.

That's much more of like just being in a, a heightened stressful situation on a semi-permanent basis and humans aren't made for that.

Brett: something you touched on, but we didn't sort of fully define, which is what is the job description of an excellent engineering manager?

Marcel: Yeah. This is, um, this is probably one of the more talked about questions, broadly speaking.

 in my estimation, an exceptional manager. Know, sort of by the nature of the question, you have to excel across multiple axes. You would immediately think this is someone who makes their team a lot more effective. And there's just so much that goes into that. But then they, they ensure their team have all the resources they need to predictably deliver high quality work to the rest of the organization.

Cuz that's, that's setting up their own team for success. An exceptional manager is a great recruiter. They're great at retention, they're great at cross-functional relationships and operating with their product counterpart or their design counterpart and really up-leveling the team broadly. And they're great at giving their teams like very clear direction on what they should be doing. And I said a lot goes into that and oftentimes people trip up when they're trying to do that for the first time. Um, where I see most first time engineering managers tend to struggle the most is. In setting and holding an appropriate expectation for members of the team. And, and I, I sort of use that word by term appropriate intentionally because good management is situational management. You, as I mentioned before, you may have senior people on the team, junior people, someone who's going through a tough time personally, someone who's just lacking general engagement right now, or, or someone who's learning a new tech stack. And each one of those requires a different level of expectation, support, and encouragement.

Um, and I, I think that's where your exceptional manager knows how to deal with those situational differences in a, in an effective manner. They don't bring the single hammer to every problem in front of them. They look at the situation, they really assess it, and then they look at their toolkit or, or find new tools for their toolkit in order to motivate and support that individual.

The that's. Sometimes glossed over is when you're managing a team, you are both managing a group of people and the dynamics that come with that, but also individuals on the team and really working, getting to know them, working with them, supporting them, and motivating them on an individual basis. So I guess I just said a lot about what is required of an exceptional manager, but part of the reason they're exceptional is they can at some point do all of these things.

Brett: I think that's interesting that you highlighted that expectation setting is so difficult and I think when people talk about great management today in 2023, I think they go to this idea of supporting teams and helping them be effective and developing talent. But I feel like part of the piece that's often lost.

Is that you're also responsible for the results or the outputs of the team. Um, and my guess is when you talk about expectation setting, that's kind of part of the idea that you're getting at. And maybe when you think about new managers and you think about the polar extremes, there are some people who are commanding control.

We have to get this thing done and live in that world. There may be others that are just like a support system helping people, so on and so forth. But you kind of need both that idea of setting direction clearly, which is expectation setting and that sort of support concept, developing talent. And so maybe you could say a little bit more about expectation setting and what it means to you and how you would help a new manager develop that muscle.

Marcel: So expectation setting is critical and it's, I think there's a strong appetite from members of every team to know what is expected of me and how best can I help. Um, every business is in some type of challenge. They're trying to grow, expand, survive, and everyone on the team, every day they get up and they want to contribute to success.

They wanna be a part of that, and they all recognize that, doing that together. Is the most effective way to do that. But now we need to know what are our expectations in order to deliver on these outcomes. And I think it's important that managers, the way I view it is an effective manager is gonna set a high bar in terms of what the expectation is.

They're gonna be really clear about that bar, and then they're gonna support their people to get there, find out what they need and help them to get to that point. But it's a shared goal because we've set the bar to, like, the bar has been set and well understood. Now it's a shared goal and it's how do you get people to that level?

So there's expectation setting as part one, and then there's supporting people to land those expectations as part two. I also think when you're talking about new managers, this can feel like a different muscle. You're, you're being really explicit with people who maybe were your, your peers not that long ago, and you're feeling really explicit with them about, here's what I need you to do, or Here's what is expected of you. And then you have to objectively evaluate people against their expectations. I think that's something that feels very different to new managers. And I try and encourage them to look at this not as judging people on the team, but rather as being the reporter of facts and presenting a mirror to people so that they can see how they executed and have additional context about how their performance has impacted others on the team and how it's perceived by others on the team.

And it's a manager who can provide that feedback to people in a way that feels natural to them, as opposed to asking their peer, Hey, how did I do? And we certainly want cultures of feedback and direct feedback, but people oftentimes feel uncomfortable about doing that, and for a variety of reasons, they feel much more comfortable with that coming from their manager.

So I, I always encourage new managers to lean into that and really, Provide as much fact-based evidence as they can to people about how they performed relative to expectations, and also being really clear about what the next set of expectations are. Um, this, I I try and pitch it in a more positive sense, or the most positive sense in terms of if you're writing someone's promo packet, the person has done all the work to get promoted, you are there as a journalist and sort of chronicling it, but they've done the work and they deserve the credit for it.

And people, people like that framing. They wanna get into that. And what I try and do is also say that's the same role you play when it comes to setting expectations or engaging in performance management. You are providing facts to someone so that they can observe what they're doing and change their behavior as needed.

Brett: How do you think a new engineering manager should figure out if they're setting reasonable or unreasonable expectations for the team?

Marcel: This is a good point where they can leverage those other managers around them and their own manager. But there's definitely something in terms of observing how the team reacts as expectations are set. If the team is completely freaked out, you can sense that as a manager and you can sort of ask, is that what you were expecting?

Does this align? Do you think it's some, is this an aggressive but reasonable goal? Is this something we can land? And it almost doesn't matter if the answer is yes or no, because what you're doing is opening up the space to have a further dialogue about it and sort of dig in more and understand what are the, when I say we're gonna deliver this feature in this timeframe.

What are you thinking about? What is your immediate reaction? What is that like? Why is that not already aligned with the estimates you provided? Like what, what was different about what I said versus what you had previously provided? And sometimes they're really great answers there. People might just be saying like, oh, my estimate didn't take into account the bacon period or the beta period, or testing.

And that's an opportunity to sort of, okay, well let's, let's revise that. Let's ex, let's do a better job of taking into account all the things that are involved in estimation. But it's also a good opportunity to ask, but why didn't we take that into account? Why did you opt for this more aggressive timeline?

Because that may tell you a lot. It may be that people are operating an environment of fear and they feel like they need to give short estimates on things so that they can move on to getting work done and get, get projects green lit, um, when really it's, it needs to be a bit more of a conversation about everything that's involved.

Um, but I, I think it's really important that even though a manager can. Sort of that expectations with their manager or with their peers, it's important that they have a direct conversation with their team about that, because it's not gonna be the last time that you're setting expectations and you'll wanna get sort of more aligned every time you do that.

Brett: How will, how much of a stretch is healthy, do you think, when thinking about expectation settings? because my, my guess is that, that some of the nuances that you, you kind of want to be pushing, you want to be right on the edge. Um, at the same time, I think a lot of the thinking around OKRs where you hit them 60 or 70% of the time, a lot of issues with that in that it can be very demotivating.

And on sort of the other hand, if you're crushing your goals, you, you have the risk of having a sandbagging culture or one where you're not getting the most of your people or demanding the most of people. Um, and, and that where you set the bar just, it feels profoundly important and maybe slightly underexplored.

Marcel: Absolutely.

Brett: goal setting, but it's done in a very squishy way, and yet it might be the most important thing, sort of where's the bar set

Marcel: Absolutely.

Brett: of as the manager of the team. And so anything come to mind for you there?

Marcel: Yeah. I think when you talk about goals and expectations, that's, as I mentioned before, sort of the job of the manager is to set clear expectations and then support their teams towards getting there. That's half the job, is setting the expectation. Um, and I think there needs to be a healthy tension when it comes to, and I use that term, advisedly, healthy tension when it comes to how much you want the team to stretch.

Um, the team should feel like they're stretching and accomplishing something big in major because that's like the sweet spot. It's feeling like we, it's, it's almost what requires and encourages the flow state is being able to do just enough to get that accomplished and feel like you were stretched and learning along the way.

Um, you wanna avoid is setting expectations and, and obviously they're the extremes of too high and too low, but even just a bit too high. You get in situations where projects slip, teams feel like they're on a death march at the end. Um, and there's, even when you launch, there's like not a sense of of accomplishment.

It's more of like, well, we missed the date, but we launched. Um, and dates are, you know, some are arbitrary, some are real, but dates are the way that organizations express priority. So I, I do think it's important that there's, as a function, dates are involved, but. As you're setting those, those goals, if you're, if you're hitting your goals 80, 90% of the time, in my estimation, that's probably too much.

It's probably the case that you've not set them aggressively enough. Um, part of this is if you set your goals fairly aggressively and you're hitting 70% of them, you're probably still making progress on the other 30%. It's not that you're not making progress. Where I see OKRs or goal setting go sideways at times is having too many, like when you've got eight or nine priorities or top level OKRs for a half, at that point, people on the team start asking like, wait, am I contributing to all of these?

Some of these are all of these equally important, and in reality, at the business level, All are important. There're probably two or three that are really important. And those are the ones you, you just wanna be clear and transparent in terms, again, of setting clear expectations. You wanna drive home the point that while we might be hitting 70% of our OKRs, we're gonna hit all three of these because that's existential to the business.

We need to make sure we hit those. And I think having that level of clarity is something that everyone appreciates because it helps everyone make the appropriate trade-offs and microdecisions, that's one of the reasons you wanna have a shared understanding of goals, is you don't wanna bottleneck on decision making.

You want everyone to have enough context that they're making the right decisions at their level and scope, um, without having to like run it up the food chain or run it up the flagpole and ask people a bunch of questions. You've empowered them to make decisions. You've given them the right context, OKRs or whatever is your planning and prioritization framework or helping them to make the right trade offs.

And as a result, things are happening faster.

Brett: Can you think back to maybe a team that you were managing or one of your engineering managers managing over the last few years, and maybe tell us a story of what good goal setting and context setting might sound like for a given quarter or a year or. Any way to kind of bring it to life.

Marcel: Yeah. I think, um, an example of this is a, a fairly recent example was when I was supporting the Slack Connect team at Slack. it was somewhat of a zero to one project. Slack Connect was, first of all, slack is a, a product that many people use at work for communications. Slack Connect was allowing you to communicate from one organization to another.

It breaking the organizational boundary, it. And one of the things that I came to appreciate as I was working on that team, prior to that, I primarily supported the core product experience where the main constituency there end users who are interfacing with the product seven, eight hours a day. But as you move into something that's crossing organizational boundaries, one of the things that I really came to appreciate is that the role of admins or owners is really, really important there because they wanna make sure that their information is protected, that the company's indemnified from any sort of legal action.

There's a lot of controls in place at that level. And as we were launching this product, I think we overly focused initially on the core product end user experience. We wanted to make that fantastic. So we spent a lot of time on the invite flows and the response flows and how that would actually happen and.

When we were doing our initial alpha and beta customers, we were dealing with organizations that were opting into this. So we didn't spend as much time on the admin tools and making admins feel comfortable. became clear as we launched to production that that was an area that we had underinvested in.

So when it came to goal setting for the next quarter, we really focused on how do we improve that experience? And the goal setting wasn't in terms of setting projects, it was really in terms of setting the right metrics, in terms of approval rates and admin engagement. And then we empowered the team to sort of figure out what are the right levers to pull there, do your research, talk to admins, find out what the friction points are and deliver on that.

But it wasn't leadership telling the team this is how to do it. It was leadership telling the team, this is what's important and this is how you'll measure it. How you get there is within your purview. And I think teams really appreciate that. One of the things you hear from all organizations when they do their engagement surveys is that a critical part of employee engagement is the sense of autonomy and being able to actually have an impact and make decisions that matter.

And if you empower a team by giving them the, the goal and the outcome that's meant to be achieved and then the support to get there, but they get to make the decisions about it, that's much more empowering for the team than if you lay out here are the specific projects. And in part because that ladder approach is less effective, the chances that you know what the right projects are at the beginning of the quarter and that they're gonna sustain through the entire quarter or half or whatever period are pretty slim.

And if you're relying on an executive leadership feedback cycle, it's gonna take a long time to course correct from your initial. Theory or hypothesis until you actually have a working solution. But if you localize that decision making and feedback loop at the team level, knowing that you're aligned with the outcomes, you can get there much more quickly.

The team is closer to the problem and they can iterate more quickly. Of course, that that's a, a situation where that can cause a little bit of anxiety. If you don't know exactly what the team's doing, you can feel a little anxious about it. So it's not meant to happen in a vacuum. There's still gonna be regular check-ins with leadership and whatnot.

But I think there's a, a difference in cultures where teams feel like they have the autonomy to do this type of work. And where teams feel that they're ticket takers and they're following a directive of this is the feature to build in this way. And you can see it play out in the way a product is built, the, the employee engagement, but also the end result.

Brett: I wanted to jump around a little bit to a couple things that you mentioned. One is an interesting one, which is this idea of when you become a new manager, new engineering manager, for some folks, you end up managing people who you are very good friends with. what are your thoughts or coaching on folks trying to figure out how to do that well or not get tripped up?

Marcel: I always advise people in those situations to recognize that that awkwardness does exist and that both parties are aware of it. It's not something that's like, just in the back of your head, it, it is actually a thing. And as with most relationships, it's best if you actually talk about that openly and kinda get that outta the way.

Upfront. I also encourage people to look at it, not necessarily as a hindrance. One of the first things you do if you're managing a team of new people new to you, is invest a lot of time building those relationships. If you've already got those relationships, it may require some adjustment in terms of how you interact with folks, but at least you're starting from a position of having got a base relationship there.

I think it's important to be explicit about as your manager, I will have your manager hat on and I will be providing you this type of feedback. and recognizing that that's gonna feel a little bit different at first. And in my experience, it actually feels most different for the person who stepped into that management role.

The person who is the. I think it's relatively rare that they have issues with that. Um, in part because when this is done well, it's something that's signaled to the team for a while. People on the team are in support of it. They recognize this person as a defacto leader, and this maybe just a, a now it's a different experience where they might have gone out for coffee before and asked for help on something.

Now they're getting feedback in a, a performance review. It's a different venue. The stakes feel very different, but it's the same type of communication that's going on. Obviously, there are gonna be challenges if there's a performance issue or something, and now it feels very different. Um, but again, that's where new managers should recognize they're not in this by themselves.

Most organizations have an HR department. you've got a manager yourself. There are people you can lean on to help you through that first pass of doing your first difficult conversation of type X or Y.

Brett: you mentioned kind of the idea of making the implicit explicit. When you transition into that role between this person who was a good friend of yours, can you share more about what you think that conversation should sound like? I.

Marcel: It's almost a setting of the, the rules of the road, the rules of engagement, if you will, at some level. and it, I, while I think this is most pronounced when you're dealing with someone who was a peer, who now becomes manager, I also think this is really important for managers who come into a team as a new person on the team and they're inheriting a team that exists cuz there are dynamics there that are at play that are, they're different, but they're strong dynamics.

And in both cases I encourage people in this first couple of one-on-ones to have a written document. It sort of lays out from the reports perspective, how do they like to receive feedback? are the things that trigger them? What are the things they wanna do? What are their ambitions? where do they feel they need to be pushed?

Because I think this is something where you kind of alluded to this a little bit before, but um, management has taken on, there's a pendulum between being supportive and really being driving. And what you really want is some combination of both. And I think management is maybe in its more recent era characterized as it should be more on the support side and less on the, the driving side.

But if you ask people again in these employee engagement surveys or just in conversation, what is it they most want from their manager? They're not getting it's direct feedback that helps me become better at my job. I mean, I, I can say that verbatim because I read it in every performance review of a manager that I cover.

Everyone on their team wants that. But as I think it's somewhat human nature, people, some people are reluctant to provide that direct feedback to people, even though that's what they want. But if you sit down with someone at the beginning of this type of relationship and ask them what do you want in terms of feedback and how do you wanna receive it, they're gonna tell you they want constructive direct feedback.

And when they write that down and you've sort of at it's hard, not do that, they're asking for it. A polite person, you're, and it's your job. You're meant to deliver it. And I think there's, now you transition from should I be doing it to, how should I be doing that? And that's where you can really have that conversation with someone and understand what's the, what's gonna be the most effective way for me to provide that feedback to you.

And that's like a first pass in practice, there are gonna be times where you just need to deliver feedback right away. Sometimes it's best written so that someone has a chance to read it and gro it and process it. But I think that's something that once you establish those sort of rules of the road, whether it's someone who is your peer and is your friend, or someone who you just met and now you're, they're gonna be reporting to you, that helps set the, the table for how this relationship will go.

So I encourage people to really invest in that and take the time to establish that at the beginning of a relationship because it's something they can leverage going forward.

Brett: You mentioned this briefly, but what, why do you think that is the case that most of the time, the number one thing that a direct report wants is more feedback. And I, I think it's particularly curious because you know, if you are not the c e O, you're generally reporting to someone else at some point in the org.

So you are on the receiving end of this. And my guess is there's an odd duality. Where you have engineering managers asking their director of engineering, for example, the number one thing they want is more feedback. And at the same time, if you talk to their direct reports, they want more feedback. And so it, it, it's sort of a, an odd dynamic cuz you are, most people are both managers and customers of the management experiences.

They go up even in a small org where you might have two management layers. What, what, so what do you think is going on there?

Marcel: I have a theory about this that, uh, this is a hot take. My hot take here is that when most managers feel they have delivered a bit of feedback and it's something they geared up for, they're maybe thinking about in the shower that day. They, they wrote something out and they deliver it in a one-on-one. The person receiving it does not think that they got feedback or that it was constructive or actionable in some way. And I think it's, you know, you can consider that maybe talking past each other. You consider it maybe sugarcoating things too much. But, um, I think the reality is we are never as explicit as we think we are. And as a manager it, it's almost painful to say, I have some direct feedback for you. It's like, I wanna frame this as letting you know that the next sentence I say is gonna be feedback so that when you leave this 1 0 1, you can ask yourself, did I get feedback? And you can point to this sentence, right?

And it seems so pedantic and so sort of, um, you know, at some level contrived. But I think it is critical that we are very clear that I'm about to provide some feedback or I have some feedback for you and positioning it in that way. And I think one of the major reasons that people don't do the or that doesn't happen.

Is because hearing the phrase I have some feedback for you, causes some people to get defensive right away. And as a manager you notice that. So you try and weave the feedback in amongst other things and now it's watered down and it doesn't come across as feedback. So I think it's, it is born of a place of trying to like, perhaps make people feel comfortable, but it has a very different effect.

It makes people feel unsatisfied. So I, I think it's something that, again, once the relationship has been established and people have maybe done this once or twice, it becomes much more comfortable. But there's a huge activation energy to having that happen the first time.

Brett: Kind of an offshoot of, of this that I think is maybe slightly underappreciated is that excellent managers are excellent at exiting people out of their org. And my loosely held opinion is most managers don't exit folks enough. And most new managers really struggle with us. Um, and I'd be interested, you know, I, I don't think a lot of companies talk about excellently letting people go or when they're evaluating someone as a manager.

They rate them on, how good are they at exiting people from the team? I think they talk about developing people, setting directions, sort of those things. But it's not, it's not discussed. Right. And so if a manager hasn't let anyone go this year, either they're genius recruiters, which there's almost nobody that's, that's good.

Or there's a chunk of the, the team that hasn't sort of been appropriately exited, it's, it's obviously not a fun conversation to talk about, but I find that there's not a lot of teaching of how to ask people to leave or when to know when somebody should be exited from the org. And so I'd be interested in particularly, cuz we're talking about this mainly in the context of new managers.

H how do you support new managers in developing this ability, which is gonna be unfortunately, an important part of their career if they want to be an excellent manager.

Marcel: I'm gonna give you the, the hot quotes first, and then we can get into like the specific answers. And I, it's a hot quote because someone delivered this to me early in my career and it was like an epiphany moment for me. I, I credit this person as I repeat it to other people. If you could replace this person on your team with a new hire today, would you do that? And that's a very different question than, are you ready to fire this person? But when you get people to think in that context, oftentimes it comes down to like, yes, I would do that. I would take someone who would put through the interview process and they passed over this person who's been in seat for some number of months or maybe longer. And once you've established that, the next question is, and I remind people as managers, they're often the last to know this, but if you feel that way, how do you think everyone else on the team feels? Who works with this person closely all day? And those two questions are usually enough to get people to look.

They may not be ready to fire someone on and firings a tough term, but they not ready to exit someone. But they're thinking about performance management in a. I think in terms of like how you get people to feel comfortable with this being a reasonable part of the job and that they get better at it, most organizations will do some form of calibration, like maybe on a every six month cycle. And what you described is what I've observed in every single calibration I've gone to that was not for the most senior people in the organization. So principal engineers, the time you get in the room, there's healthy and active debate instantly because people have such high standards for those folks. But every other calibration I've gone to at some point I've thought to myself, and I'm, I'm dating myself here with this reference, but I thought to myself, Is this Lake Wobegon or all these kids above average? How is it possible that everybody here is meeting expectations and we as an organization hit 70% of our OKRs or we, you know, some we didn't deliver certain projects.

Like was that our expectation? Of course not. So what happened and helping people understand that as a manager, you are in part a capital allocator as well as a talent evaluator. Talent evaluation does not start and stop at the recruiting phase. It's something that's ongoing all the time. And performance management is a regular thing.

That's not a a dirty term. It's not a negative. We, you shouldn't experience that as a negative connotation because when done correctly, and I think part of this is people jump to the exiting and they don't sort of think about the step right before that, which is performance management or that should come upstream of that performance management when done correctly.

Some. Set of those cases will turn around and people will be positive contributors to the organization. They, they will become refocused, they'll better understand what's expected of them. They'll have better support structure around them. There'll be some things that will be uncovered as part of the performance management process that will help some subset of that succeed.

And then for those people who go through that and they don't succeed, something that I think all of us, you know, we sort of intuitively know, but people are afraid to say that person isn't having a good time. If you've been on a coaching plan or a pip and you know you're not doing well, you, you really do know that Everyone knows that and at that point, dragging it out.

I, I see like new managers, they'll say like, well, let's give it another 45 days or something that's just asking this person to suffer for another 45 days in some ways, and I think when you recognize that there is a gracious way and a humane way to exit someone and help them leave the company. Then you view that as a much more reasonable thing to do than to ask someone to go through another 45 days of this constant evaluation, feeling like their job and their future is on the line and that they're underperforming. And when people are underperforming, they've given it a good shot and it's not turning around. Sometimes what they need is to go to a different role in a different organization. And I've seen people thrive after doing that. Part of it is they find a better fit. Maybe it's that they're, they had some things in their life that they need to take care of, but I think it's something we're, when when things aren't working, you need to make a change.

And it's not just for yourself as the manager, because I think it's somewhat of a selfish thing to avoid those hard set of conversations. You're doing it both for that other person. Clarity is kindness, but you're also doing it for the rest of the team. As the manager, you have an obligation to the entire team.

That the team is represented well, and that you're upholding the quality bar for everyone on that team. So, you know, even though it's a team and everyone's holding each other accountable, really it's the manager who has to enforce that accountability. And I, the, the reason I remind managers about this is from personal experience.

I've been in situations where I will hear from people on the team, so and so is not doing well. They're, they're underperforming. I can't rely on them. And when I, at that point, my first reaction is always to say, okay, let me go get more information. I'll talk to that person about how they think they're doing, but I'll also pull other people on the team.

It has never been my experience that when I pull other people on the team, they're like, oh no, no, this person's doing great. It is always my experience that they're like, that person has been struggling for months. And I start asking like, how am I now hearing about this directly? Like, why is it that this didn't come to my attention before?

And I realized that's not a question for me to ask someone else. That's a question for me to ask myself because I should have been closer to it and understood why that's happening. Um, by the time, and I was, by the time someone on your team is telling you about a performance problem, they're no longer running a clock on that person.

They have been running a clock on you because they think you should have noticed it before they had to bring it up. So I view that as like, okay, time to get moving. And like, it doesn't mean you need to be exiting someone the next day, but you need to be actively engaged in that performance problem immediately.

Brett: So let's say you're a director of engineering and you have five ENG managers that sit, you know, that report to you that you're responsible for.

What should that person do to help their direct reports develop this muscle or be really excellent at letting people go?

Marcel: So I think the first part of that is evaluating talent and doing the performance management exercise. I actually think engineering directors are uniquely positioned to do this because while I talk about a calibration process happening, and that's typically like at the VP level, directors can do informal calibrations with their directs.

On a regular basis. In fact, they should, I would appreciate that the directors on my teams are doing this at the mid-cycle calibration. They get the managers together and it's relatively low stakes here. It's not a rating that's going into some official product like Workday or something. It's, it's a conversation that's being had. And I think at that point, directors can really set the bar and also the expectation for how you deal with a problem. When a performance problem is identified there, directors can engage with that manager and, and with the other managers there in terms of setting the example and really point out, here's what we're gonna do to support this person and this is the crucial part for me, and here's the timeline at which we're gonna have resolution one way or the other.

Brett: Yeah, pre-commitment contract.

Marcel: Yeah. Like Exactly. And especially like when you put a timeline on it, that because dates are how organizations express priority. Now it really focuses the mind. It's like, okay, this is gonna go one of two ways in the next X, you know, 30, 45, 60, 90 days, whatever it is that you choose. Um, now that everyone sort of sees, okay, we're gonna, and, and then at this point, it's important again for the engineering director and the manager to model to everyone.

This is what a best effort looks like cuz we're gonna make a best effort to turn this around. It is in the organization's best interest financially. It's in our best interest to have this actually turn around if it can, because backfilling positions takes a long time. All this stuff, we've already invested a lot in this person, but if we determine at this point that we've made a best effort and we haven't turned it around, this is what a graceful exit looks like.

Modeling that for folks and sharing it in advance so that people know what the tools are and what the escalation path looks like. Often the case that, especially for a new manager on a team, It's a scary thing to hear the terms performance management and exiting someone, they don't actually, if they haven't done that before, they don't actually know what that means.

Am I gonna have to get in a room with this person and tell 'em they're fired? Like, like what does it mean? What are the logistics of it? And helping to explain that situation in advance sort of makes everyone feel more comfortable with it. And knowing that it's not a rash decision. You get up on one side of the bed one day and you determine you're gonna fire someone.

But that there's a, a formula and a expected set of steps that gets us to this and that we feel confident is the right decision when we get there.

Brett: Any other trip ups or mistakes that you've seen in your career around firing well or creating a culture that does it well that's worth flagging for folks? I.

Marcel: I'd say the number one area where I see people trip up on this, and this is new and experienced managers both. Is that they wait too long to get the process started. And it's a process again, you don't wanna like just make a rash decision. It's a process. It takes time. Organizations typically have a timeline in mind when this is happening.

And I think what happens is managers don't wanna have the initial hard conversation and then document that conversation cuz it feels so real. But because they don't do that, they live in this world of frustration and their team being frustrated and they reach a point where the breaking point where they're just like, okay, this person has to go. And they go to HR and they're like, we have to let this person go. They've been struggling for a really long time. And HR says, have you documented anything? And, and the manager's like, well, no, but trust me, it's been going on for a long time. And HR says, okay, well here's what the process is and here's how we're gonna do it.

Now the manager is like, gobsmacked that they have to wait 30 days to do something or 45 days. And they're frustrated because they know the team is looking at them like, why are you letting this linger? And it's a situation where they didn't get ahead of it as soon as they could have. And again, I think it's performance management is a part of management and it's something that people should feel comfortable looking at and engaging with because the sooner in a process you start, the higher the likelihood of success in turning it around.

But if you wait too long, it's gonna be difficult.

Brett: To go in just a slightly different direction 

If I were to listen to you or watch you manage your team or teams in the past over the course of a week or a month or a quarter, are there questions that you come back to all of the time, things that you tend to ask people to sort of prompt them or help them or get them unstuck? I think we obviously spend a lot of time talking about advice, perspectives, and I have to think some of the most significant ways to help someone is by asking them excellent questions.

And so I, I'm curious, are there any that you tend to go to 

Marcel: There are a couple that I, I feel like I repeat myself a fair amount with. Um, I, I'd be curious, actually. People on my teams felt like they thought it was repetitious, but, I'm often asking them, What is the maximum upside here and what's the maximum downside to try and get a sense of, have we thought through the trade offs and what could be potential outcomes? I guess probably the most common question I'm asking, because I spent a lot of time in execution and delivery reviews is what could go wrong here?

What's the thing? What's the thing you're most nervous about and what's the thing I should be most nervous about? And, and I really ask those two questions together because it frames it as there should be two different answers. And the second answer is one that's the most enlightening for me. Um, the thing they're most nervous about is typically something under their control.

And the thing they think I should be most nervous about is something that they don't expect to resolve on their own. They expect me to. And it could be that it's still something they can resolve, but it's not their expectation. So by asking that, I can surface some of that to myself. Um, something I try and ask more often, and again, this is a work in progress as we all are. But, uh, you know, I, I oftentimes start one-on-ones with like, how was your weekend? Or What's going on? How are, how are you doing? I've started to ask people, what was the best part of your work week so far? Or what was the best part of like, the last work week? And hopefully that one is coming across as being repetitive.

I'm trying to make a pattern of it, but it's a nice segue to like people to sort of celebrate something they've done and for me to be made aware of it, but also it's a natural segue to what was the most challenging part as well, and people feel comfortable surfacing that. Uh, it gives me something to act on.

Brett: Perfect place to end. Thanks so much. This was fantastic.

Marcel: Thank you Brett. I really appreciate it.