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

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

 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?

 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.

 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?

 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.

 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?

 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.

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

 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.

 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.

 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,

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

 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%.

 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.

 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.

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

 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.

 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.

 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.

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

 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.

 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.

 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

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

 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.

 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.

 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.

646e79b72030dd6ae3fad930

Marcel Weekes is the VP of Product Engineering at Figma, and was formerly VP of Engineering at Slack. He unpacks why most startups get it wrong when they uplevel someone from IC engineer to eng manager and unfurls what stellar engineering management looks like at high-growth companies.