How to Leverage a Non-Technical Background in Engineering Leadership | Melissa DePuydt

0:00When I became a product engineer at the Post, I felt like I really had to hide my background. There's definitely imposter syndrome and kind of shame of like not having a technical background. But the longer I'm in engineering leadership roles, the more I'm really grateful for my background as a reporter because it allows me to make decisions really quickly and gather information and look across contexts in ways that I think a lot of engineering leaders often don't. How do the best software engineering organizations in the world set and track goals? Linear B worked with more than 3 ,000 orgs to effectively track their KPIs and set goals.

0:40And March 26th and 28th, Linear B's CTO, Yashai Beery, is hosting a workshop to share those best practices with our fellow engineering leaders. This workshop will delve into the data behind effective goal setting, strategies elite engineering organizations use, successful companies that are using goal setting, plus provide a free how-to guide and reporting slide deck for you to leverage. You can register today at the link in the description. I hope to see you there. Hey, everyone. Welcome back to Dev Interrupted. I am your host, Connor Bronsden, and I'm delighted to be joined today by Melissa Depoit.

1:14Melissa is the Senior Director of Engineering at Upstatement. Melissa, great to have you at Dev Interrupted. Thanks for having me. I'm so excited. It's a pleasure having you here. I'm very excited to talk about what you're diving into as well, because you have a background as a reporter and editor. And you've also been a leader of engineering teams at both The Atlantic and The Washington Post, which is a really unique background, I think. Most folks don't work in media. And it's led you to have this perspective on how engineering leaders need to learn how to think like journalists. Can you unpack that a bit?

1:49I'm a career switcher. I started out as a journalist and reporter. As long as I can remember I've been writing. When I became an engineer, I found out that a lot of the things that I enjoyed about reporting and journalism, you still do them as software engineers. And so writing code is a lot like writing a news story. Editing and reviewing PRs is a lot like editing and reviewing story drafts. So it was very natural for me, with the exception that you don't have to talk to strangers and like chase down an angry congressman for a quote as a software engineer. So I was like, sign me up. And the longer I have been in product engineering, the more I have become really proud of my background as a journalist.

2:35Because at first, when I became a product engineer at the Post, I felt like I really had to hide kind of my background. There's definitely imposter syndrome and kind of shame of like not having a technical background. But the longer I'm in engineering leadership roles, the more I'm really grateful for my background as a reporter because it allows me to make decisions really quickly and gather information and look across contexts in ways that I think a lot of engineering leaders often don't. So for me, I think that my background as a reporter helps me think about situations differently and try to discern the essential context for something versus just trying to wait for more information when I make a decision.

3:20This is really interesting for me, in part also because I share a similar background. So I didn't actually tell you this before we came on the podcast and started chatting, but my background's in political organizing and communications. So kind of the other end of the journalism spectrum. So it's interesting for you to bring this up because I agree with this. I couldn't see my career unfolding differently because of the unique skills and challenges that were brought to me. Yeah. And it definitely has informed my perspective on software engineering and software engineering leadership. So I'd love to go a bit deeper into the areas where you particularly see these needs for changes.

3:56What would you say are the keys to bring over from your background that you are now leveraging in the software engineering space? Yeah, I think the first kind of mistake that I see a lot of engineering leaders make is not preparing for the risks and disruptions that you're just going to encounter. Over-optimism. Over-optimism, over-optimizing for like, it's all going to be great. This is finally going to be the quarter where like our roadmap doesn't shift. Oh, man. I have a surprise for you if that's what you bet. Exactly. And the truth is that no matter how well we plan, no matter how well we roadmap, there are always going to be disruptions.

4:37And I think accepting that is kind of a journalistic, the first step in adopting a journalistic mindset. Because a news reporter knows that news is going to happen and they expect breaking news to happen at like the most inconvenient times. times and a journalist doesn't get a choice in delaying how how they're going to respond. They just have to respond well. And so I think that's where engineering leaders can can learn a little bit and, you know, just start to plan and prepare for what we're going to encounter in the course of our daily work. So that high degree of comfort with change and the ability to adapt to it.

5:19Yeah. And knowing that, you know, it's not a journalist's job to prevent the news from occurring. Yeah. It's their job to respond well. And I think the same is true for engineering leaders, although obviously we want to be mitigating risks where we can. Our job is to respond well and to hopefully create clarity for our teams. And so there are several things that I think that engineering leaders can do specifically to both prepare to respond well and then to respond well in the moment. I think that preparation piece is really crucial, right? Yeah, it's to me, it's like an iceberg. What you see is someone who is really good under pressure and good at making decisions.

5:58And what's underneath the surface is just this wealth of preparation and mindset management. And yeah, just putting yourself in the position to anticipate curveballs. And when you are better prepared for like any one type of curveball, you're actually priming your brain to be able to handle all types of curveballs. Yeah, a mentor of mine kind of referred to it as looking around corners and developing that skill. Yep. And I think that's something that is really important, regardless of the type of leadership challenge you're taking on. But it's also true for individual devs, I would even say, where it's like you're really what you're doing is you're being an excellent problem solver with a unique skill set.

6:39And so like that ability to see what's the potential problem coming down the line, how will this impact other things we need to do is really important. Yeah, so a lot of newsrooms will have multiple kind of like processes for managing different types of news. Because most journalists don't just roll up to the office on Tuesday and they're like, well, we'll see what happens today. Hope I have something to write about. A lot of news organizations are kind of extensively planning for news coverage and trying to really remove the number of things or reduce the number of things that are truly breaking news moments.

7:16And when those things do occur, they have plans that they activate and processes specifically for breaking news. And I think that's where engineering leaders can start to think like journalists by saying, what are the disruptions that are likely to occur? How can I start to monitor for those things now? And how can I prepare for how I will respond when those things happen? Can you maybe share an example and talk through how that would be implemented if you were an engineering leader? Yeah, I personally am very anxious. I've never had a problem asking myself what could go wrong and coming up with answers.

7:59To put it into practice, I really like running premortems with my team. And so a premortem is similar to a retro, but the opposite. in that you are asking your team to kind of reflect on a period of time and kind of say what went wrong, what could have gone better. But with a premortem, you're doing it before anything catastrophic happens. So can you dive a bit more into that? How would I actually go about that? You assemble your team and you ask them, put yourself in the perspective of we're in the future and we're looking back and assume our project has catastrophically failed. What went wrong?

8:39And you essentially ask the team to generate plausible reasons for failure and then come together as a team and start to identify, all right, what are the things that are likely to occur and how can we mitigate them? And so when you do this, you are using what research calls prospective hindsight, which is like deeply an oxymoron. And perspective hindsight, the research shows it actually makes you 30 % more likely to correctly identify the causes of failure before they occur. And so in starting to think about those things before they happen, you can put together the plans and monitor and say, what are the signs that we're going to look at that will signal that production is down or will signal that we need to shift our roadmap?

9:30And so you can start to put plans in place that you can activate when you notice those risks occurring and respond faster. So, for example, would you look at this as, OK, we have a major feature rollout we're doing and, you know, it's coming out from under feature flag if you're using it. And we still have concerns. Let's do a pre-mortem to evaluate where there might be challenges and maybe we make additional fixes before we're rolling it out. Or how would you do that? Yeah. So when I was at the Atlantic during the kind of first few months of the pandemic, we were embarking on a front end redesign and rearchitecture project.

10:04Major project? Major project. Huge modernization effort. It was a huge win that we got to do this project during an election year as well because it was back in 2020. And so before we began on this like massive project, I got together with my team and said, all right, our deadline for launching this is like right after the election in November. It's a really tight timeline. This was maybe in April or May of 2020. So we had six months. Let's assume that we do not, that we haven't hit our goal. Like we get to November and things have gone wrong. What caused us to slip our deadline? And so what the team came up with was like a number of things that were production like goes down and we have to like change our focus or a new mandate from the leadership came and we have to.

10:59That's never happened. That's never happened. And no, you want to identify those things in advance. Because really, I think the engineering manager's job is not to like prevent everything from happening, but to be able to respond well when those things do happen. And so a lot of those things did happen in the course of that project. But because I was in the position to be able to say, no, I was anticipating production going down. I was able to build in a couple of weeks for like extra time. Like if that happened, I added that as kind of buffer in our timeline when I was planning what we could like feasibly implement.

11:42So another example of the things that we identified was like, yeah, QA. What if we're just like behind and we're not, you know, we're not as far as we want to be when we're like testing things. And so I worked with our QA team to say, like, what are the ways that we can incorporate the QA team much earlier in the process so that it's not just kind of relegated to this final two weeks right before launch? And so in identifying those things, I was able to more effectively manage them. And we got to launch. It was one of the best launches I've ever had the pleasure of like doing just because we were so prepared for the unexpected to happen.

12:22When you implement these premortems, is there a correlation with increased planning accuracy on what you're actually delivering? Totally. Because what a premortem lets you do is say, like, what are all of the possible reasons? And so there are those very big kind of like catastrophic things. Like, again, production goes down, that kind of thing. But it also led us to say, like, what if we overcommit to what we think we can deliver? And that caused us to kind of step back in a separate planning session and say, all right, we know that we are worried and we have a tendency to overcommit. How do we need to scale back what we're telling our product leaders we will be able to deliver?

13:09And so that led us to have this strategy of like, let's under promise. And obviously, this is always the goal, under promise and over deliver. But we were really careful about what we committed to and only committing to the things that we could really confidently deliver. And that's so great because it becomes a situation where you can start to have more predictable project delivery. And realistically, that's what all businesses want. Exactly. And that, yeah, that's exactly your role as the engineering manager is to create the conditions for your team to reliably deliver. So you're a senior director now, but it sounds like you've been doing this since you were an engineering manager, a senior engineering manager.

13:50How do you make sure that you get buy-in from other leaders on how you're changing your processes and leveraging these post-mortems or pre-mortems, I should say? Yeah, I think that it's so unusual to have this kind of like intense planning for things to go wrong that honestly, it's really easy to get buy-in because business leaders, I think, are much more accustomed to like, things are going to go wrong. Engineering leaders, we think it's our job a lot of the time to mitigate and prevent things from going wrong. And so it's really uncomfortable when we're in those situations. So when it comes to like being more proactive and being better prepared, I found that other leaders in the business are like, we want to do that as well.

14:36Yeah, yeah. I think this is a great example of leveraging the skill sets and approaches taken from other industries to improve how you are functioning as an engineering leader and how your teams are functioning. But it sounds like there are other insights that you've brought over from your time in journalism as well. What are the other insights that you would leverage for other engineering leaders? So I think that a lot of what I've mentioned so far, like the premortems, preparing, accepting the reality of unexpected disruptions. Those are all things you do in advance of something happening. And so when journalists are actually in a breaking news situation, it's their responsibility to not just gather all of the information about the event that's happening, but to really filter through it.

15:24And in covering the news to tell readers what the essential context is. So in a lot of news stories, they leverage what's called the inverted pyramid. And the inverted pyramid is a very common and classic story form in news that focuses on putting the broadest, like most essential information up top in like the first paragraph and then gradually layering in more important details. And what happens is that, you know, as a reader reads the story, they get the extra context. And so it's not just to use, I guess, what's been in the news cycle lately. It's not just that there are attacks. It's that there are attacks in a certain place, and that place has context and at a certain time, and that has a certain context.

16:15And so when we're trying to make decisions as engineering leaders, I think what we can do is start to layer in additional context that help us make our decision. And so what that looks like is asking yourself, not just like, what's happening? What are all of my possible options? But going a level deeper and saying like, what team resources do I have available? What are their skill sets? Layering in organizational context and saying, what are the broader business goals? What are the stories that our company tells ourselves about who we are and what matters? And then finally, like the personal context of like, what is a decision that you can live with and what matters to you in how you're responding?

16:59And so leveraging this kind of thinking helps us narrow down options and find a narrative for ourselves. And that way we can make faster decisions because we've narrowed down based on kind of like these other contexts, what are like feasible options are. And we end up with a short list of approaches that are all good because they're all informed by context. And when we take this other context into account about the team and the business, we also are identifying kind of the factors that can allow us to change our minds. Because it's okay to be wrong in making a fast decision. If the context changes, we can also change our approach and start to, again, leverage kind of that journalistic thinking of if I am presented with new information, what do I need to update about my thinking about the context of this story?

17:55The thread that I'm hearing throughout what you're saying is this limiting of cognitive load under crisis. Absolutely. Yes. Yeah. And I think that, I mean, we pointed to how that can improve your planning accuracy and predictability of delivery earlier, but it's also going to likely improve the quality of your decision-making in the moment and your ability to, to your point, rectify some of these challenges you may have otherwise. Yeah, I think, you know, a lot of us, I'm totally guilty of this. We get focused on looking at the event that's happening. When we're in a moment of crisis, we're like, what is happening?

18:30Production is down. And we're like, but we don't know why. And so our tendency is to wait for more information. and that can actually delay our team's ability to get production back up. So I might not know why production is down, but I might have like additional team context that is that it's in the middle of the night for the team. And so there's not a lot of resources like that narrows down my possible paths of action to be something that is much more manageable. What's your experience been like when you leverage these techniques, whether it's the premortems or other ones you're talking about, to try, like, what's been the feeling from the team members themselves about, you know, these additional meetings, additional things they're having to do?

19:17I think that every engineer wants to, like, write good code and have a stable environment where things are not on fire. And I think that they are willing to participate in those meetings because they are directly in service of more focus time, more flow time. And so there's less of kind of like pushback I've experienced because these are really targeted conversations. So how are you getting your team to buy in on this? I mean, additional work that's being done in advance. I think that I get buy in by starting to persuade the team that if we are more prepared, we will be less disrupted in the future when we're under pressure.

20:08And so having those proactive conversations, really a lot of the work coming out of it is for the manager to be able to monitor, but it also puts the engineers in the mindset of being prepared for disruptions and knowing that our goal ultimately is not to ship exactly what's on our roadmap. It's to build and maintain a really great product experience for our users. And so the most important thing is not necessarily executing exactly the roadmap, but responding well. And it's really stressful for engineers too when those fire drills happen. And so I get buy-in by saying, like, you know how stressful those crisis situations are.

20:54If we meet now for 60 minutes, we can possibly prevent a two-week disaster recovery situation. That makes total sense. And it's interesting to hear you talk about this and how you're kind of adjusting your team's perspectives, or at least having them expand their perspectives in some ways. Because, you know, we talked about this earlier, but I think we both think that this ability to look forward and consider potential challenges is a key trait to develop as a leader. And I would posit that this may also be helping develop your team members as leaders and having them be more of this mindset of like, how is my individual work affecting customers, affecting the company?

21:36Are you finding that to be the case? Yeah, absolutely. I think that a lot of engineers think that, you know, their job is just to just to write code. But when we want to think about growing people and stretching and putting ourselves into uncomfortable positions so that we can grow, it involves bringing in kind of bigger business context that a lot of engineers don't like naturally gravitate toward. And so, again, it's like it's being proactive about saying, like, how will you respond in in a moment of crisis? And I think helping people shift from like, oh, we just have to react to something, to whatever happens, to a more thoughtful approach of like, no, we can actually be deliberate.

22:23We can have processes to handle unexpected things. that actually makes people feel a lot more confident knowing that we have plans in place and it's not just going to be a mad scramble. Do you think that part of this need to bring in these concepts is a problem with how we train engineers to be kind of individualistic thinkers? Whereas once you actually get out into, I'll call it engineering world, you are usually it's a team sport. Totally, yeah. And newsrooms are a team sport too. Like you get a lot of journalists who are like, I'm just a reporter. I just want to go out and cover my thing. But in reality, it's cross-functional work.

23:07You know, there are not just reporters, but also photographers, videographers, social producers, editors. And so it's a very similar kind of mentality to engineering. How should we adjust training for engineers to enable this forward thinking about, hey, this is a team sport. We should be kind of thinking around corners. I mean, I think that a lot of the skills that we kind of naturally gain as we move through our careers as engineers, as ICs, are the exact scrappy kind of skills that we have to still leverage as managers. And so I think it's less about training ICs and more about helping ICs understand as you progress the types of situations you're going to be in.

23:58Most of the time, you're going to be trying to like be in this like scale mode of having an impact at scale. But when unexpected situations occur, we can shift into this other mode that we're actually more familiar with because that's like a lot of engineering. Yeah. This is a really interesting look at preparation and the approach you're taking here. Are there any other insights around preparation or mindset that you're bringing from journalism that you want to highlight? I think what I just mentioned about kind of having a scrappy mode and a scale mode is something that a lot of journalists cultivate.

24:37Journalists are people, too. They don't always enjoy being on deadline. And so a lot of reporters will kind of have this one set of skills that's much more kind of like investigative. And it's really kind of when you need to tell a story that is deeper and you're digging deep, you're kind of asking questions to get more context. that is in stark contrast to a breaking news situation. When you're on deadline, you have to act swiftly. You have to focus on just the key details and not like everything about like the past situations. And so I think that's another thing that engineering leaders can adopt as well and give ourselves permission, honestly, to switch modes and make decisions differently when we're in a moment of uncertainty or a moment of crisis, because at least I've certainly been told that like, as a manager, I always have to be focused on growing people, scaling, like process.

25:34And it's really important when moments of crisis occur to be able to break from that and to shift into this like scrappy breaking news kind of mindset. And so the way that I use this is when I'm in the normal course of work, I'm in scale mode. I like to make decisions by building consensus on my team and getting everyone's input, making sure that everyone is aligned. And when I'm in a moment of like crisis or intense pressure, I give myself permission to kind of abandon that. Everyone doesn't need to be involved in giving like their opinion. I need to commit to an approach. And so I give myself permission to shift into that other mode where it's not where I spend the most of my time, but it allows me to act faster.

26:21And that then creates more clarity for the team. And that's what they need in those moments. This is really interesting, too, in a cultural context, because this egalitarian leadership style that you described versus kind of the more authoritative under pressure is something that is very, it's often seen in a lot of Western countries. So the U.S., Denmark, The Netherlands, for example, very egalitarian approaches. Whereas if you look even at like Spain and Italy, they're more on the authoritative side or hierarchical might be a better phrase here, let alone like Japan, Korea, where you get this kind of more hierarchical approach to leadership.

27:00And so it's interesting to see how that is to flex at times, depending on the circumstances. Yeah, exactly. It's a sliding scale. And what I do is like I apply this in any given situation by saying like, what mode do I need to be in? Because often when you're making decisions as a leader, it is decisions, plural. It's not just one decision. It's often a series of decisions in quick succession. and so I will put myself in a mindset and just take a beat and say, what mode do I need to be in? Is this a situation where I need to focus on creating opportunities for my directs and empowering them? Or is this a situation where I need to be super scrappy and do it myself?

27:46Or I need to be super scrappy and make a decision on behalf of the team and guide what they're doing? Do you have any thoughts that you would share for other career switchers who are thinking about how to leverage the knowledge that they have or how to adjust to the kind of the new track they're on in engineering? I think that being a career switcher is actually kind of a superpower, especially as we move into leadership roles where our deliverables are not necessarily primarily code. They are often interpersonal. They are often written. I do a lot of writing as an engineering leader, just like writing documentation, writing briefs and memos.

28:28And so I think that for other people who have come into engineering from a non-technical background, whether it's a boot camp or you're self-taught, really think critically about what the other skills you have are and how you can leverage them in the context of your current team. And I think you'll find that those things actually, yeah, end up being advantages because they're skills that you don't learn as engineers necessarily. And so a lot of that is working in teams or, like I said, writing. And so I would really encourage all career switchers to be proud of their backgrounds and to really try and bring those skills to the forefront.