The Best Solution to Burnout We’ve Ever Heard

With registration for our October INTERACT conference now open, we wanted you to hear one of our favorite sessions from this past April’s INTERACT. Featuring the best minds from Slack, Netlify, and Ambassador Labs, our session on Inspiring Engineering Leaders & Driving Developer Creativity turned into one of the best conversations we’ve ever heard on topics like dev toil, focus, and burnout.

This is a great preview of the type of content we’re working on for our conference in October, and this panel completely made us rethink how we approach burnout at LinearB. If you like it as much as we do, be sure to sign up for October’s free virtual INTERACT conference.

Episode Highlights Include:

• (7:44) The collective strength of the developer community
• (14:15) Developer toil and reducing interruptions
• (23:23) Enabling creativity 
• (26:16) Slack's "Maker Week"
• (33:34) Ensuring people are seen, heard, and celebrated
• (42:24) What to do with talented devs that are not suited for the management path

Transcript

Dan: Hey everyone! Welcome to INTERACT and our Inspiring Engineering Leaders panel. I'm your panel moderator Dan Lines, I'm the host of the Dev Interrupted Podcast and co-founder of LinearB, and I get the pleasure of introducing our panel participants, the new faces of engineering leadership to you. So, I'll start out with Dana Lawson, SVP of Engineering at Netlify, and also a veteran Dev Interrupted community member. Dana, welcome to the panel.

Dana: Thanks, I'm excited to be back on the show. It's always an interesting conversation when you join this rodeo. I love it. Thanks for having me.

Dan: Awesome. Next, we have Milena Talavera, a VP of Engineering at a little-known company called Slack. Milena, welcome.

Milena: Thank you so much. My first time here, super excited!

Dan: Yeah. Awesome to have you on. And we have Katie Wilde, VP of Engineering at Ambassador Labs.

Katie: Hi! Thank you, I'm happy to be here.

Dan: Awesome. So, I'm incredibly excited to welcome all of you to INTERACT. It's going to be an amazing day of learning and networking and an opportunity for us all to continuously improve. Let's start by getting to know our panelists a little bit better. Obviously, you are all very, very successful leaders in your own right. But Milena, we'll start with you. You've been promoted at Slack three times in the last five years and are now leading Slack's infrastructure organization. What has the experience taught you about how to grow your career?

Milena: Yeah, I mean, I've been lucky to have found a supporting place, you know, where leaders and people recognize my impact. But I think in terms of what I've been doing, I've been doing myself is, you know, really I try to focus, you know, not so much on the promotion, but, you know, what can I do to better, you know, the company, the culture, the team, and really focusing on that. I try to take risks, you know, when appropriate and sort of dive in, you know, definitely many opportunities were like, oh, Milena, you know, can you do this thing?

Milena: And, you know, I hesitate for a second and then I'm like, okay, I'm just going to dive in and do this. So, I think it's, you know, I've had the support system in place, but also, just really try- like, I like to feel challenged. I like to feel mentally stimulated, and so I look for those opportunities where I can drive improvement for the company and the team. And so I think that, you know, that has been paying off in my, my career so far.

Dan: That's awesome. Dana, I saw you shaking your head yes when Milena was talking about a support system. Did anything hit you around there hearing that?

Dana: I think it's incredibly important, you know, to feel at every level of your career that you have people advocating for you, that you have care and concern within the culture, because everybody has their own bespoke needs, but we also have general needs, and having a very supportive culture really enables people to take those opportunities and stretch themself, because if you don't have a safe environment, you probably don't have psychological safety and then you probably don't want to go and do something bold and the way to grow is to try and try again and be supported in that effort of trying.

Dan: That totally makes sense. Developer experience and productivity is so important. We're going to dive into that a bit. And actually, it leads well to Katie, what you're doing. So, you've taken on a new challenge with Ambassador Labs. Previously, I think you were three years being a successful leader at Buffer’s engineering team, but at Ambassador, just reading a little bit about it, it is about enabling developers to ship faster, ship code faster.

Dan: What are some of the learnings that you're bringing over to Ambassador from your time at Buffer?

Katie: Yeah, well, it's my first time doing dev tools, right? And it's great data. Like I'm never going back to the office.

Dana: You’re never gonna go back! You won’t!

Katie: It's just so inherently fun. Like, I just love it. But Dan, to answer your question, you know, the learnings that I'm bringing over, I think Buffer was remote from, you know, from date dot, very strong global remote culture. And of course, that's now very common post-pandemic. But what I'm really bringing to our Ambassador is building an inclusive, supportive, remote-first culture that allows people to really unlock their creativity and kind of, scaling up their team and building that out, given that it's the sort of remote-first world. So, Ambassador was a startup that, it started out of Boston and kind of was a co-located team, fairly quickly went remote in a sort of remote-friendly way, and then with the pandemic, decided, okay, we're going to be absolutely like, remote for us, remote only. We are a distributed team, sort of TM, and we're going to scale that way. So that was one of the most important things that I was bringing to the table with our scaling journey.

Dan: Yeah, that's awesome. Let's just dive into engineering productivity. It's one of the key themes of this conference, you know, how to make your developers and your team more productive, enable developer productivity. You know, Milena at Slack, it's all about improving communication, and Katie, you just spoke at Ambassador Labs. It's about improving developer experience. And Dana, of course, all of your time at GitHub, that's just like, the mecca of the world of developer experience and productivity, and now at Netlify.

Dan: So, Dana, we'll start with you. I know you're a big advocate for open source and democratizing access to solutions as opportunities to improve productivity. Can we start there and unpack what does that all mean and your reasoning behind it? I mean, in this day and age, we technologists have done such a great job of building all the Legos out there in the world, and I look at this opportunity and the way that we share that, because I will fight anybody on this that you can't tell me the collective strength of the human developer community is better than is not better than your team. There's just no way. There's no way, and I think when you think about this opportunity of putting very different affinities of thoughts and very different experiences, and you coalesce to create something that enables all of us, then we get that benefit. And when we talk about developer productivity, don't tell a developer, I've said this before, how to do their workflow, like don't even do it. Like they're going to have their own way. I've seen some really amazing setups from, you know, an insanely sophisticated THUM, to like, the foot pedals. Did you know you can have foot pedals for your development workstation on iMacs? Oh, yes, you can. And so, what I love about it is really saying, well, technology's moving fast. We know that there's new solutions being invented by all of these great people. And companies too are not alone, because we're seeing this now, rise of corporations saying like, wait a minute, open source isn't going anywhere, and so the more that we contribute to it, privately and publicly, we are going to enhance developer productivity and velocity because we're not making them choose just the thing that we said is right. We're opening it up and looking at it wide and saying, okay, what's out there? And it's difficult, right? Because depending upon where you are in your lifecycle, you may have much more higher compliance needs. There may not be that passion yet to say, oh my goodness, I don't know who all these randos are that ship this code, but once again, technology is meeting us where we are and putting in the right levels of gates and abstractions to wash away those fears. And you've seen this rise, I would say, very dramatically in the last ten years, you know, where we thought everybody was going to go Cloud. Well, now everything is in the cloud, basically, and we're interconnecting it for speed, reliability, and it's just all coming together. And so, I think you can't have one without the other when we talk about open source and developer productivity.

Dan: Yeah, absolutely. Katie, what do you think about that? I know you're now spending some time at Ambassador and, what are your thoughts?

Katie: Well, I mean, I do agree with Dana and two of our main products- like, our two main products, Ambassador Edge Stack and Telepresence, like we donated them to the CNCF. You know, we're like, these are our business projects, we've donated, they're part of the ecosystem because, you know, we want to be in the cloud ecosystem for us as a company.

You know, for us, success means that ecosystem is succeeding. And of course, like, there's a paid version, like we have to make money somehow. We have investors. You know, there's that, but it's not about like, trying to lock down IP. Like, nothing about this is like, oh, we have some clever idea no one else could come up with, like, no, not at all. You know, we're very upfront about our, you know, our ideas are technology, like what we develop. Like, we have donated these products to the Cloud Data Foundation and I will tell you, it's a good recruiting draw. I know that's something that, you know, is difficult for all of us right now. And it's really important for the sort of overall success that we're making this ecosystem succeed, and it's all built on open source. And honestly, I would go a step further to say that if you… If everything you're doing is totally proprietary, there's a bit of a trust issue, I would say, emerging, where like maybe in the past that was okay. But now, you know, we're selling paid versions of a product where there are supporters, maybe different features.

But the fact that it's built on open source, the fact that it's a CNCF project, the fact that it's built on things like Envoy, that actually adds a layer of like, trust in there that we wouldn't have. It was just, just ask these people and we don't even know what that code is, you know? And that transparency and the trust really go hand-in-hand, so. And that's an interesting thing. I kind of hadn't really thought about that until I actually joined Ambassador, and they were like, no, no. Like, this is not, how do you make money despite open source, this is like, a crucial part of our sales cycle now, you know, which, news to me, it was very interesting. Yeah.

Dan: Yeah, very cool. And Milena, of course, Slack is enabling an async workforce with digital-first productivity, but going beyond just tooling, like how do you think about the entire ecosystem of engineering productivity for your developers?

Milena: Yeah, I mean, it's definitely multi-dimensional, I would say. I think, you know, for when we think about sort of the bigger picture and the team overall, if the team is not aligned or doesn't- is not behind, you know, kind of what the company or the larger team is trying to do, then I feel like the motivation is not going to be there.

And so, I think this is sort of like the outer layer of the product productivity. I mean, to me, which is, you know, do you have OKRs or whichever way you choose to, you know, create that alignment for your team, you know, along with the company. So that to me is one dimension. Then when we look at the team as a whole, you know, what is the state of the team? Is the team just, you know, barely keeping afloat and just working on, you know, hitting the pagers and like it's just, is not able to innovate.

I think it's important to reflect and understand that. because, you know, that can influence the work you prioritize. And then I think third, it's like going a little bit, you know, sort of deeper into the execution layer. To me, first of all, I think one disclaimer, it's never about the individual. It's always about the team. And so like, some of the key metrics we like to pay attention to is, you know, what is the cycle time of a PR or a time to merge for the team, you know, holistically and that, you know, that influences the work we prioritize. So, I think it's those three dimensions to me holistically, you know, can influence kind of where we invest our time. You can observe those metrics over time and see like, okay, are we making a difference, you know, with what we're investing in and prioritizing? So beyond, you know, just like what features are we building, how are we operating as a team? Is the team motivated? Is the team aligned? Is the team spending most of their time on, you know, just operations versus, you know, moving forward progress and other things? So that's kind of how I how I think about it.

Dan: Yeah, that's awesome and like, totally interesting. Of course, it aligns with a lot of the things that we sometimes talk about in the Dev Interrupted community. One of the things that we're focused on, and we'll talk about that later in the conference as well, but there's kind of this idea of developer toil or interruptions and reducing interruptions. Dana, if you have any thoughts about that, or how do you think about saving your developers time and getting them focused?

Dana: Well, I read a really great article and I apologize to that author out there, your name passes me, but they said “shipping is the heartbeat of your team,” and I was like, oh wow, yes! Because that's a pretty standard indicator, because we're trying to remove friction, right? Just like in life, you know, a good experience in life is a nice paved path where the things that you want to do and the things that you want to grow on are really exciting and challenging, but you're not coming up and being annoyed by the thousands of paper cuts, and so when you start to look into those metrics and you start to see where you have this low hanging fruit, you'll find that it can be anywhere in that supply chain or in that lifecycle. And if you utilize it at the team view and say, how do I use this as a benchmark to understand if I'm creating friction? Because when we know, like I had the pleasure of working with Dr. Nicole Forsgren, Accelerate, new article space, I love it. It's an emphasis on where we've gone with the door metrics, to now how do we invoke flow? How do we keep and capture that innovation? Because now we're going and saying, I want product-minded engineers have agency, I want them to dig deep and really feel what they're producing from an experience perspective. And if you have a really terrible engineering system or if you have broken windows or if you don't have intentionality on finding out where that friction lies, then you're going to interrupt flow, and their research says for every interruption, when your head's down creating, it takes, on average, twenty-three minutes to get back in the zone, and if we think about those multiple times a day, you have hours spent, hours spent. So, I think they go hand in hand and really what we're trying to solve for is not the activity of shipping, even though it's a good way to go, it's stuff flowing through the systems, it’s really the quality of the results and the way that we feel when we are shipping, because when it's easy, you just want to go, go, go. But if you're getting- you're just getting stopped and blocked, your motivation goes down. And right now, the world's hard enough. Like, at least what we can do as leaders make it better. And so, I think you have to just take a step back and say, how am I inspiring my team by ensuring we have the right level of systems and knowledge? And we're moving that friction, so they can do the best work of their lives that inspires them, because they're going to give that gift to the world.

Dan: Absolutely. Milena or Katie, do you have any thoughts about how you keep your developers in flow or reduce interruptions? Is there anything that you're doing around there?

Milena: Yeah, I mean, so something that we're starting to do more recently is try to measure that toil. You know, I think for infrastructure area in particular, you know, you're owning, operating your complicated services. And so, we're trying to understand like how much, you know, how much time to your point, you know, twenty-three. Like, you get a page and maybe it's quick to resolve it, but the twenty-three minutes around it, like that time is lost. And so, we're trying to understand like, how much is the team getting paged? How much of it is outside of working hours? You know, how many triage requests when your customers are coming in and asking for help as a signal, both to interruption, but also like, in the usefulness of what you built. So, we're starting to look at that and it's been very effective because we can really just, you know, set markers and really drive improvements that way, because I think if you just- you can get into this hamster wheel of like, well, I guess that's just how it is or maybe like we need to hire more people, and yes, you can always you know, add more people, but that's only going to be a Band-Aid. That's not going to be the, you know, the underlying solution. So, we think we are starting to look at measuring that and have seen success in driving it down in that way.

Dan: Yeah, that's awesome. And, you know, in terms of interruptions, you know, I'm more familiar with the PR process and all the interruptions that can happen there, and we have some data that shows if a PR, let's say you start the review, and that review goes over one day, twenty-four hours of time, bad things happen after that. Then the reviewer has to come back in and do this cognitive reload and get out of the flow and then get back in flow and then change requests and all this flow that Dana, you were bringing up, becomes completely broken, so if we can like minimize those exchanges back and forth, great things can happen. Katie, is there anything that you do with your developers around either saving time or kind of like, scheduling to help them stay in flow?

Katie: Yeah, so you mentioned scheduling, and of course, you know, developers don't like meetings, so be very mindful of your meetings. I'm sure this is not news to anyone, but something that I do is I look at the devs’ calendars and I'll do something where I'll just like pull up a random person's Google calendar, and I'll look not at how many meetings they have, but how fragmented their days, and really encourage myself, my engineering managers, anyone who's scheduling meetings to defrag the calendar, and it's just like a hard drive, if you've got five hours of heads down time, but they're all in forty-five-minute chunks between this customer call because we want you to be a user empathy focused dev, and now you've got this demo that you've got to do and then you've got an interview, whatever it is, like these are all legitimate asks, you’re just not gonna have any flow. If you can defragment a calendar so that you create these sort of uninterrupted stretches of time, or at least while there's not a meeting or that there's not a known interruption, that helps a lot. And I mean, that is kind of difficult because typically managers, exec, whatever, you have the busier calendar. So it's like, oh, I'll just squeeze these people in wherever it is. And then I understand that. But the defragmenting of people's calendars is something that they will often say to me you know, thank you. That actually helps more than you maybe realize that did. That actually does change, you know, the feel of my day and the flow of my day. And the funny thing is, is, you know, I hear a lot of people wanting, you know, in this climate and with the pandemic being so hot and with burnout you know, wanting to be the sort of person first team, and then when you have people saying, like, we gotta ship it, we gotta ship it, it feels like they're at odds, and I just wanted to say that developers want to ship, that is flow and that is what beats burnout. So please don't hear this and say this is like, oh, like push your team really hard to shove. No, no. I can tell you that if your team is not your team is not shoving, that is burning them out, and if they are experiencing a lot of flow, for most devs, that's fairly restorative. So, please don't misunderstand us and hear this as a, you know, burn on culture, I gotta ship all the time. It's like, no, no, it's not shipping that's burning people out. It's the toil, it's the broken config, it's the three-day pull request review, it's the PM with another meeting about something that you are, you know, that's the thing.

Dan: Totally make sense to me. I love that you say it's like, a restorative thing to get your work out to production. It's an energy increaser.

Katie: I wouldn’t say that, like, for every human, it's like that, but like, we have an industry where people are typically selected into this industry because they want to do the task. Like, we're not forcing people to dig ditches. You know, they often have coding as a hobby as well. You know, this is something that's not unusual. You don't have to, you can be very successful, nothing like that. But for a lot of people, like, the job is something that they choose to do and they would enjoy doing. So, if we could just get out of their way, you know, that would be great.

Dan: We look at, you know, we talked a lot about the idle time and the toil, and you can come from it from a data perspective, which we do oftentimes. But there's another angle to it that I really want to dive in here and it's around the creative aspect of it. And Katie, you're getting to that, I think a little bit. Developers allowing for creativity, rejuvenating your soul, your brain, and you talked about scheduling a bit. How do you think about enabling creativity or protecting for creativity, allowing that time for developers?

Katie: Well, I will say that, you know, at Ambassador, they have this pretty interesting way of working. I should say we, you know, I'm new. So, this is a very interesting way of working here where we follow a, like a shape up ask model where there's a six-week cycle where a business goal is presented to a team, and then the team is tasked with figuring out how to meet that business goal so they are not tasked with delivering, okay, here's three points and this task is one point, and like, you're really taking tickets. They're tasked with, okay, this is what you need to achieve. People need to be able to automatically have bad code rolled back because we all understand why that would be useful, right? Look at that business goal. Great. How are we going to do that? So, there's a lot of ability for people to be creative and to come up with solutions that, you know, might surprise us, that we may not expect. It's not a perfect system. Like, sometimes people do run into trouble or they need a little bit of support and they're like, well, I'm not really sure what you want me to do. So, you know, like, any system, it has its rough edges, right? But it definitely optimizes for having people think and be part of that solution. And then there's these six weeks that we are doing this kind of like, meeting the business goal work and the team sort of ship after six weeks, and if they're not able to ship that thing, we don't automatically extend it, you know, that we don't have these long-running projects. We'll revisit and say, okay, clearly this is much harder than we thought. Does the business have appetite to continue investing here or not? We want a time box that, we don't want these sunk costs. So, that's very helpful at a startup. I mean, I imagine, you know, Slack is quite different. Like, you probably have projects that are going to run way longer. Like this is not, you know, cargo cult advice, so bear that in mind. And in the next two weeks, we don't tell the engineers what to do at all, and they also find this confusing sometimes. So the things are, you have to do something that's valuable to the business and you have to have a plan. You have to tell us, what are you going to do? What is your plan? And as far as, surprisingly, you know, what they do, sometimes they will, you know, go around and they'll be doing lots of refactors and quality improvements because they have that idea, they want to improve quality. Okay, sometimes they're going to fix some tooling, sometimes they'll make a POC, but that's kind of built-in, and we don't tell them what to do. So, that's really interesting. It's definitely a system that I would say optimizes aggressively for engineers’ creativity.

Dan: That’s awesome. You brought up like, Slack, for example. Milena, I have a few notes that you've spoken about in the past, so I know that you're on your team, you're doing something called maker weeks, and I also know that you've mentioned something about how investing in automation, I think at Slack, can buy back future time for innovation. So, catch us up on what does all this mean?

Milena: Yeah, a few different things. So, maker weeks is something newer we're starting. We used to have maker hours, and kind of touches on what you said Katie, where, you know, it's- you’re fragmenting your calendar, but this is synchronized. So, the entire engineering team product, everybody is, you know, week- now it's a week where you are, any recurring meetings are gone. You know, of course, you can collaborate and pair and code and things like that, but it's really just to create focus space, and so, you know, the team is super excited about it. Actually, this week is our maker week. The other thing, which I think ties to it well, is that you know, I definitely have seen in my career, you'll have teams that have so much toil where they just can't get out of it, and you really have to decide to make a hard choice where, you know what, I'm going to drop some things, or I'm gonna- not gonna deliver features for some period of time, so I can buy myself time back and invest in this toil, and then I can, you know, then I can have space for creativity. So, I think it's, to me, it's super important to get out of it, otherwise, you can continue going in that hamster wheel. And then the other thing that we do is we have, you know, that's focused just purely protecting innovation time is, this is within my team specifically, but having innovation day and the various teams do it in different days, you know, it's like once a month or every couple weeks, you know, your mileage may vary, but this is the time where it's not a hackathon where you can work on like, cool product feature. It's really, you can decide what you work on, but what we found is that teams work on things that make them more productive, you know, whether it's like this like inefficiency in their flow that they've been experiencing and they automated or something that they've been wanting to do. So, those are kind of the different ways we're tackling an innovation in focus time together. But I think it's, you know, it's… It has to be deliberate decision, you know, in many cases from leadership to create that space for the teams otherwise, you know, they like- they will continue to be in that hamster wheel because, you know, they're trying to do what's best for the company. They're trying to do it all. But you have to make those tradeoffs.

Dan: Yeah, that's awesome. Dana, I know for you, you've already brought up flow a bit, I know it's an important topic for you, and also, you're tight with Nicole with the SPACE framework, one of the founders there, yeah. I'm not an expert in SPACE, but can you tell us at all how SPACE can relate to flow, or are you measuring anything around there? Like, what are you doing around flow that can help people?

Dana: I mean, it's everything that Katie and Milena said. It's a combination of all of these things and there's not one size fits all. You have to really determine all of the variables, right? And like for me, I'm in a in a hypergrowth startup and so like, capturing the market at a right time, you know, you can't pivot and index one way or the other. You have to look at everything that's coming in and make those decisions, but it's about seeding that culture and pausing and taking the breath and saying, you know, we know we have all of these things to do. We could boil the ocean, but where can we start putting attention and then really driving that, because we do something similar, right? We have net elevation days where it's like, just be creative. It's the whole company, like the whole company. We want all participation. We want people to live and breathe and understand other areas too within that are sitting and saying, you know, block your calendars, pay attention- I love that defrag to your calendar like that, oh, love that. Defrag your calendar. But I think it takes leaders showing up and showing that it's important as well, and it's challenging, right? Because if you look at the work style between like, a manager where managers, doot doot doot doot, meeting meeting meeting meeting, especially when you're digital first now because you need more interpersonal relationships. But I try to get my managers to show up like their engineers, where's your creative time, where's your space? Where's your optionality to work on things that make everything better? And so, there's not a one set way, and I think you can still utilize the baseline of the DORA metrics to be that guiding- those guiding principles to say, okay, we can measure our engineering systems and now we know some data on top of that that just applies the human condition on top. Let's start with the stuff that's obvious and work and iterate on it and find those opportunities. But I think it's about from that first time you hire saying, we want you to be creative, we want you to be innovative. The best ideas can come from anywhere, you know? Don't put a box on that. And then as you grow in scale, think about how you can refine that. I know that's kind of like, wishy-washy, but at the end of the day, you got to take a step back and measure, right? You got to measure and benchmark, and then you got to understand your culture and you got to understand what's valuable to you, and I think we can all agree that when people feel their best, it's once again when they're seeing that progress, right? It's not about the activity, it's about the tempo of how you're getting your ideas out. And if you have a steady tempo that's measurable, then you know that flow’s happening. Unless you've got a lot of bots that are doing pull requests and chores, and then you've got a really great bot system. But for the most part, it's some indicators there, and I think that you have to just take a step back and start there, especially if you've gone down that journey, if you're starting to, you know, don't try to solve everything. Start with the DORA metrics, time to deployment, meantime to recovery, time for review cycle, start with the basics and then grow from there because it's really easy. It's a trap to read all this amazing documentation and be like, we got to do all the stuff, don't do all the stuff. Do the stuff that matters, measure, look, observe and talk to the people. I think there's a combination too, that goes along with how you measure that health and toil, and we do this like from a people perspective. It's like, you know, making sure that you're doing CSTAT stores internally or maybe we should call them ESTAT scores, engineering statistics. Are you happy when you wake up in the morning and not, you know, in the company of you, but really about what you're providing as a leader and as an organization? So, I think you have to take the human feelings which are heart-driven and back them up with your mind and apply that to your engineering systems where you know, you can make change.

Dan: Absolutely. Yeah just, I mean, doubling down on what you're saying, I mean, if you're not using the DORA metrics. Yeah. I mean, this is like foundational stuff, high leverage points to improve. Find your bottlenecks, make sure you're measuring, do what's best for your team to keep them in the flow. That's, you know, obviously LinearB, but there's tools out there that will help you do that. So that's the foundational stuff, and I want to kind of transition us, but stay with you Dana. One aspect of creativity can be around ownership, and I'll tell you why I think that's the case. If I'm getting new responsibilities or things are being delegated to me that I've never done before, and I might be an engineer or an up-and-up-and-coming manager, that's exciting. It's a new thing. I can be creative there, but also for new leaders or newer managers, it can be really scary to like, let go of the reins and give it to someone else, and I want to dive into that topic of delegation and ownership a bit, and we'll keep with you Dana, how do you think about delegation and, you know, making that happen within- you, you've been in large organizations like, how do you do it?

Dana: If you're going into management just to tell everybody what to do, like, don't go into management because that is not what this job is. It's about, you know, ensuring people are seen, heard, and celebrated and that you're removing bottlenecks. So we think about delegation, I like to apply- We've heard some of the rubrics from like Apple and others where directly responsible individual, I condition you, their manager, to make it happen. I really think, you know, when we talk about stepping into these roles about directly responsible enablers and it is your job to ensure you're giving opportunities in your job to take the ambiguity down and give it into detail. And then you have to let yourself stretch and grow as well. A lot of people on these journeys, you know, you're sitting here honing your craft and one of the best things to do as a manager early on is, learn to give it up. Like delegate, delegate, delegate, because then you have to ask yourself, if I'm uncomfortable delegating, am I creating safety? Am I feeling confident? Do I have bidirectional trust or are you just overly concerned like your ass is on the line? I take a step back and say, first, let's see where there's bugs in the system. Why do you feel like you can't delegate? Are we not being informed? Are we not writing things down? And for new managers, I think it's our job as senior leaders to build some constraints, give those guiding points, but also give people space to fail. You can't grow unless you try, and you don't grow unless you fail sometimes because you're probably not being bold enough, and I think you have to really create that space to fail, and you also have to give them that space to say follow your instinct, work and build these interpersonal relationships. Ensure you're giving equal opportunity and you're delegating to the right person and guess what? You don't always get it right. You won't. You may delegate to somebody, and you don't know what's going on with them, and it may fall through the cracks, and you're sitting here going like, I felt. No, you just had an opportunity to learn and you had an opportunity to mentor and find out where that system failed. And so, it's this constant hamster wheel in some ways, but it's not the kind that's not enjoyable. It's almost like, you know, this this constant evolution and ability to come back and make it better. And when you are in that wheel of creativity, I like to think about like an impact zone, the better you get at it and the better you create that wheel, your impact grows. And so, you just have to lean on that, and I think setting people up for success means investing in your manager training and education. You can do stuff- some things intuitively, but, you know, the best artists are the ones that are practiced. You have talent, go refine it, and I think you need to do that with a manager craft as well. And one of those ways is helping the people below them grow because, that's going to enable you to grow as well.

Dan: Milena, what does autonomy look like to you when you do delegation? How do you ensure that autonomy for people reporting to you?

Milena: Yeah, I mean, I think definitely a lot of the points that Dana covered. But, you know, I'm of the… First of all, like I really get huge enjoyment out of seeing, you know, people that either work for me or just, you know, more junior growing. And so like, to seeing someone, you know, two years ago, I was like oh, I was leading an effort this size and now you see someone else do it and do it well, it just brings me a lot of enjoyment, and so like my approach to, you know, delegation and autonomy is, yes, you want to create the support system and you want for them to know that, like if they're having challenges, you're there. But to give them the space to, you know, to fail, to stretch themselves, to take those risks, you know, this is how I feel like my entire career has been, including like the first time I went into management. It was like Milena, did you want to like, overnight it’s like, the CTO left, do you want to run the team? And I was like, oh my god, this is terrifying. I went, slept on it, and I was like, okay, I'm going to do it. But, you know, it's- so I think giving and like, knowing that I don't know what I'm doing also, right? And I worked through it, and I think it pushed me and, you know, it felt super rewarding. And so, I like to create that space for people. But, you know, setting up kind of expectations, like how much do I want? It varies from person to person, like how much do I want to know? You know, like what should you communicate, etc. But I think autonomy is just so powerful because it unlocks creativity in the people. It stretches them and you just create the guardrails. It's no different than, you know, than software or even the flow, right? Like, we talk a lot about productivity, but safety, right? The safety and the guardrails you put into your development tooling is so important as well, and so I think it applies to people and in similar ways, you just want to create, you know, enough guardrails but don't meter the individual, right? Like, you know, I think just give them the space to fly and you'll be surprised how, you know, how many people just will just do it.

Dan: Gotta trust your people, and you also threw in another important tip, when an opportunity comes to you for career growth, it's usually a good idea to say yes. You said yes overnight and, you know, kind of went on from there, which is fantastic. Katie, question for you on this, how do you let someone know that if you delegate a task to them, it's okay for them to take it maybe in a different direction or like a different viewpoint than maybe you had?

Katie: Yes, so this is, I think, hard for all humans to do because we delegate the task and you know exactly how you would do it, so you think you know how like, it should be done. For me, the most powerful learning and improvement I did on myself was learning how to ask coaching questions, by which I mean, the question has not got a yes or no answer. So it's not a case of like, do you have a plan? It's a case of like, what is your plan? And you've got a lot of these open-ended questions that are not yes/no answers, and you're walking through the problem space with them and try to stay in the problem space, not the solution space, because that way you'll be able to give them that autonomy, not tell them how you want to do it, just like yourself. And I've had experiences where like, we've walked through the problem space and come to a solution. I was like, I've never done it that way and I'm going to in the future because it's clearly better, you know, because it's surprising. Somebody says, “what's your plan?” they go ah, thought I’d do this and that. It’s like oh, like, now I think there's some unintended consequences. Some might say, oh, what might be the consequences of, you know, the thing? And then they've actually thought through them and I'm like, oh, I'm wrong. Note to self: was wrong, you know? So that’s really, really helpful and actually, I don't know Dan, is there a way that we can share a resource with this community? Because I have a list of questions that like our coaching questions, I just get up in a tab when I find myself having that urge to, you know, to tell people how to do it. I'm just trying to help them, you know, and, and I just whip up my little tab. So if there's a way to do that, Dan, I'd love to send that over, yeah.

Dan: Absolutely. So, we will definitely share all- any materials that you have, but we also have a great Dev Interrupted community. We have a Discord community that anyone can join, we have thousands of people in it, and we will put it in there and we can get the discussion going, of course. We have a few minutes left and I'll try to keep us on track here. The last topic that I want to get into, this is really around supporting career growth for our developers, people that are reporting in to us, and you know, what I think is a little bit of an old school mindset, some people might say, hey, the only way to improve your career is to become a manager and manage people. But we know that we have individual contributors, these amazing creative developers that maybe don't want to go just on that management, you know, helping people path. What do you do for developers that are like, crazy talented but are not suited for the management path? I'll open it up to anyone who wants to jump in.

Dana: I believe you can lead from any seat, and you don't have to be a manager to be a person that makes change. And definitely as you get in the upper echelons of your individual contributor track, I think it comes naturally being a mentor. You know, I don't believe in the 10x developer. I'm like, no, a 10x developer is somebody that enables all the developers around them. And so, I really think you have these opportunities that can go in line because you have to look at what the value is that they're bringing as engineers. And you also have to look at now as completely being remote. I have an international team, so you don't want this one size fits all type person on your team. You want your team to match the world because the world is hopefully going to be using your product and the things that you build. And I think really having this sense of once again, ownership, delegation, agency, it doesn't matter what your title is, because if you do believe that the best idea comes from everywhere and that you can innovate and be product minded, you just have to give those opportunities, and I really do believe, though, as you gain experience, like pay it forward, like what are you doing? Like, that's our job here, is to pay it for the next person that's around us. So, one, they don't make the boneheaded mistakes you probably made, and that two, they get that opportunity to find where their passion lies. Some people may love breaking down and dissecting hard technical problems, but they don't necessarily want to do one-on-ones. They don't necessarily want to do some of the other things that managers are responsible for. I say, give them the opportunity. Why not? And then really think about how that career can translate into other paths because there's so many skills that are transferable into other roles. I've been a terrible designer, I've been a mediocre product manager, I've been an okay dev, and if I didn’t get the opportunity throughout my career to try that, I wouldn't be where I'm at doing what I truly love. So yeah, that's my two cents on it.

Dan: That's awesome. Milena and Katie, anything you can add to that for how we can encourage a great career path for incredible developers that are not looking for that manager role?

Milena: Yeah, I mean, I think one way to kind of enable it, I think is to create internal mobility, right? You don't want people to be leaving the company every time they maybe aren't sure which direction they want to go to. So that's definitely something that, you know, we do at Slack, including IC to management and then going back, you know, we have- we create the space for people to do that. And if it doesn't work out, they don't like it, you know, like, we give them the support. They can go back to being an IC. So I think that internal mobility, you know, enables you to retain those people but gives them that space to try, right? They can go be a designer, they can do, you know, whatever they're interested in. So I think that would be kind of my advice here and making it happen and really sort of putting the words, the actions that are in front of them.

Dan: Perfect and Katie, maybe a final thought? Anything that you'd like to add?

Katie: Yes. Have two career ladders. That's the thought. And if you don't have one, start with the IC one and make sure it's not IC Management. Yeah, so get your IC ladder.

Dana: Yeah.

Dan: Okay, amazing. We probably could have talked another hour on many more topics, but I'm going to wrap it up. It's been an incredible conversation. I want to thank our guests for sharing their knowledge and experiences with us today. So, thank you to all of you on the panel.

Dana: Thank you. It's been awesome.

Katie: Thank you all!

Dan: And also, thank you to everyone at INTERACT that's watching. Thank all of you for joining us. Again, my name is Dan Lines. I'm the COO and co-founder of LinearB. Our tool helps teams like yours continuously improve by providing the data, the contacts, and the automation within your software delivery lifecycle. Our tool is completely free for dev teams, so check it out at linearb.io, and until next time you can catch me every Saturday on the Dev Interrupted podcast. Have a great time at INTERACT everyone!