The Changelog: Software Development, Open Source - Engineering management (for the rest of us) (Interview)

Episode Date: May 17, 2023

This week Sarah Drasner joins us to talk about her book Engineering Management for the Rest of Us and her experience leading engineering at Zillow, Microsoft, Netlify, and now Google.

What's up friends welcome back this week on the change law we're talking to sarah drasner about engineering management for the rest of us yes that's her book she wrote that book and we quoted that book several times here on this podcast jared and i wanted to get sarah on this show several times over the last several years and finally we got her on the show so it's been so awesome getting to chat with Sarah. She's so wise. She's got so much information and thankfully she wrote the book to put it all down. But at the same time,

it was so awesome to kind of just hear directly from her about leading and managing engineering. Such a fun conversation. I hope you enjoy it. A massive thank you to our friends at Fastly and Fly. Well, you know Fastly gets our pods to you fast because Fastly is fast globally. Check them out at fastly and Fly. Well, you know Fastly gets our pods to you fast because Fastly is fast globally. Check them out at Fastly.com

and our good friends over at Fly.io. Well, they help us put our app in our database close to you, our users, all over the world. They can do it for you too with no ops. Check them out at fly.io. Jonathan Norris. So Jonathan, my main question, I guess, if I'm handing off my feature flags to you all, is my uptime dependent on your uptime? Like if you're down, am I down? We've designed into all the SDKs and all the APIs. APIs fail, right? That's a cardinal rule of the internet. So all the SDKs have been designed with kind of defaults and caching mechanisms and all that stuff in place so that, yeah, if our CDN is down or APIs are down, it'll sort of fall back to those defaults or those cache values in those SDKs.

So that handles for those blips pretty easily. And then we rely on Cloudflare as our sort of main high load edge provider. So all of our edge APIs are through Cloudflare and they're also operating as our CDN for assets. So obviously relying on a large provider like that, that runs such a large percentage of the internet means that, yeah, you're not relying on our ability to keep AWS instances running properly. You're relying on sort of Cloudflare and ability to sort of make sure the internet still works as they control such a large percentage of it. So yeah, we've architected it in a way that it doesn't sort of rely on our APIs to be

up all the time and our databases to be up all the time to have that good reliability. Well, that's good news. Okay, so how do you accomplish that? One of the core sort of architectural decisions we made with our platform when we designed it was trying to move the decisioning logic of your feature flags as close to the end user and end device as possible. So we did that with those local bucketing server SDKs that are using sort of a shared WebAssembly core. And then we have edge-based APIs that are also powered by WebAssembly to serve sort of those client SDK usages. So things like web and mobile

apps. So that's one of our core principles is to try to get that decisioning logic as close to the end device as possible. And this is probably one of the only use cases where performance really matters because you want your feature flags to load really, really quickly so you can render your website or you can render your mobile app really quickly. And so, yeah, we definitely understand that your feature flagging tool needs to be fast and needs to be really, really performant. So if you want a fast feature flagging tool that's performant and is not going to impact your uptime, check out our friends at DevCycle. That's DevCycle.com slash ChangeLawPod.

And for those curious, they have a free forever tier that you can try out and prove to yourself and your team this is going to work for you so check it out devcycle.com slash changelogpod and tell me sent you Sarah it's been a long time coming we've been trying to get you on the show I want to say for at least a couple years you've been on JS Party but not on the change law which is we call it our flagship show. It gets the most listens, it gets the widest reach, definitely your audience, I would say, in terms of your book, and then also the things you talk about. I think this is a great place for you, but finally here. I'm so excited. So welcome. Yeah, thanks for having me. And you wrote a book recently. You've written exclusively or extensively at CSS Tricks. It's a couple different

directions we can go, but I'm kind of curious about that one before we jump into your history and what you've done and the book you've written and the waves it's making. How do you feel about the state of CSS Tricks and your writing? I know it's all pointed there. What's your thoughts on that? Yeah, I mean, it's not actually exclusively on CSS Tricks. I used to write for Smashing and a few other publications. But yeah, I was a staff writer at CSS Tricks. I love CSS Tricks. I kind of grew up on it and stuff. So I started writing articles for CSS Tricks and I didn't think that they would be accepted just because I found it to be such a good resource. I think my first one was about, I basically, I benchmarked different SVG animation technologies, you know, CSS versus like six different ways to do it in JavaScript and kind

of highlighted some of those results. And I was surprised it got accepted. And then it also made a bunch of waves, like people, you know, benchmarking the waste test. It does. It draws us out. It does. Yeah. And, you know, I was quite worried about the waves that it was making. Like it was, you know, controversial article.

And Chris Goyer was like, this is great. Everybody's excited to get involved. And we're having really good conversations there. I just loved his attitude and approach to healthy debate. So I wrote a few more, and he asked me to come on as a staff writer. And I think one of the funny things, one thing I should mention to this audience, in case you're not familiar, CSS Tricks was named at a time when people were learning CSS, but it's not just a CSS platform. It is much, much more broad than

that. Like I wrote when React was first, you know, starting to be widely used in the community, I wrote like an intro guide to React. And like, you know, there's a lot of articles on there that are, I would say pretty much none of my articles are on CSS tricks are css related but i think it is it was a really good resource for web dev it still is but chris sold the company to digital ocean who's doing a great job of you know maintaining and keeping it going now you know i think chris had done so much for so many years like obviously you kick things like that off knowing not knowing you're gonna like still be doing it 15 years later and stuff um so you know it kind of moved also at a time when i i can't do that much i see work anymore for publications like that you know my role it does keep me pretty busy so um yeah it

was kind of a natural progression of things. 2015 is the first blog post that you're mentioning. So, I mean, that benchmark was like six years ago. Was that now? It's not six years ago. It was like eight years ago.

Eight years ago now? Gosh, my brain is jacked up. I was thinking it was 2021 again. Shh. Those were the days. Anyways, I'm back. 2023, here we are. Yep.

2015, though. I mean, that's a long time to be writing for an outlet. And do you miss it? Do you miss, like, that community? I do. Because, I mean, that's a long time to be writing for an outlet. And do you miss it? Do you miss like that community? And I do. I mean, cause I mean, no one's writing there that was writing there before. I'm just kind of curious how you feel about it now in terms of like, man, that was an

outlet for you. You wrote blog post to promote this book we're going to talk about today. So like, it's been crucial to you for so long. Yeah. I don't, I didn't really think about it as a promotion vector. That's not really what I used it for. But I think it has been more like cathartic to, you know, I used to be a principal I see, not a manager. And so for me to kick the tires on something, understand it in a deeper way.

And then, you know, for those who have seen my articles, they're very demo heavy, right? They're not just like an explanation of the thing. I would build things and kind of show how things work. And, you know, a lot of times when you're a principal, I see you learn things on the job and then there's no way of explaining that to broader audiences. It just doesn't scale beyond your role at the company. I really, you know, especially when I was working at Zillow and like Microsoft, I really wanted to make sure that the things that I was learning were available to everyone and like Microsoft, I really wanted to make sure that the things that I was learning were available to everyone. And also for myself, like I forget things,

but don't write them down. There's been a couple of times where even recently I was like working on a side project and I Googled how to do something in my own article popped up and I was like, damn it, I used to know this. So, you know, it can be nice to leave yourself a breadcrumb trail for things you've already solved too. Kind of an out-of-body experience to teach yourself something like you from the past teaching yourself something now. I will just say for those who remember the conversation we had with Chris after he sold CSS Tricks, I asked him at the time, like, where are you going to land?

What are you going to do? Because he has such a voice and he like, the guy is prolific in his writing. And I think he was like shoving some stuff into the CodePen newsletter is what he was saying. Like he just started like turning it into his own editorial. But I'm happy to say, because I missed his voice as just a reader on CSS Tricks after the sale. And there are still some good articles going out there. I just, I just linked one up in ChangeLog News two weeks ago, I think about pass keys that was very well written.

But Chris's voice is so prominent in my history of the web. I'm like, I want to know what Chris thinks about this, that, and the other thing. He's been writing quite a bit just on his own website now. So you can definitely still keep up. And I have been. So that is cool. I mean, Chris taught me a lot. I have a kind of graduate school back academic background where like my articles started off being not really written for the right audience,

honestly. Like it was written for a more academic audience and like essay-ish and Chris would edit it to be a little bit more conversational and down to earth. And I would go, oh, that is much more clear. One of the magic things that Chris does really well is he takes complex subjects and he breaks it down in a way that's really easy to understand and I think I got better at that through the course of working with him for so many years and you know right I can't thank him enough Jared and I've had the pleasure and the pain of editing folks over the years and it's a challenge to do that. Sometimes it's challenging to deliver it because you may step on their toes or it's like, well, hey, that was my writing and you kind of books, it doesn't really matter if it's your voice, really, as long as the technical concept comes across.

And then for the engineering management book, it was a little bit harder. We went through four rounds of editing or something like that. And they really helped the book a lot. And then there were points in time where some of the editors weren't technical because most of the book is more about management. And so they would say like, you know, I have this one line with like, people aren't pure functions. You don't necessarily put in something one day and get the same outcome the next. And they were like, no, we can't put that in there. Like people who won't understand.

That's great. If you ask me, that's brilliant. That's a keeper. Wrong audience, maybe. Exactly. There were some parts where I had to say like, no, I think this audience is going to get this. Right. As iron sharpens iron a little bit. Well, we want to get into your book and engineering management for the rest of us. But of course, this comes at the end, not the end, but after a lot of experience that you've had moving from an IC to a manager. I was just on LinkedIn trying to catch up with your history and your experience category is like very envious. It's like a who's who of corporations. You were principal lead

of Azure at Microsoft. You were VP of developer experience at Netlify. And now you're at Google, director of engineering and a core Developer Web, according to the subtitle there. So is that accurate? Yeah, it's totally accurate. Core Developer Web, the job that I have at Google is a big one. It's web infrastructure at Google. So my group owns JavaScript and TypeScript languages and libraries at Google, Build, Serve, Web Test,

three different frameworks, one of which you know is open source Angular. Another one you may be aware of because people talk about it sometimes, but it's not open source, is called Wiz. And then there's, you know, Protos, like there's just a lot of different things in this group. When you think about it writ large like all of that just as a person do you ever just like wow that's overwhelming like does it ever just just the the magnitude of it all it's a lot of stuff yeah i mean yeah for sure i do like um i'm quite honored to have a the job like this because i'm a big web nerd um And, you know, and I get to collaborate with people like Chrome, who I, you know, have adored for years.

And I think some of the mission and strategy that we get to put forth is super exciting. You know, there are days where I get off work and go like, today we enabled the success of YouTube search and workspace, which is all with this one strategy. That's really exciting. So yeah, it's a great job in that way. And as you're mentioning with the LinkedIn, I love a challenge. I get bored easy if I don't have a challenge. So that part of the work, I'll be

honest, I love. I really do. It can be hard sometimes, but hard in that like satisfying way. Yeah. That's awesome. How, I mean, if you were to give like, you know, a brief version, like how did you get here? How did you end up in this position? I think the nerd part is the real short answer. Okay. Well, a lot of us are nerds, but not a lot of us are, have your role there. Yeah. I mean, I, I Okay. Well, a lot of us are nerds, but not a lot of us have your role there. Yeah. I mean, I do think that having a lot of interest in the area and, you know, wanting to dive in and make things better, whatever that it looks like. You know, when I was a principal IC, I made things better via the vehicles of my own work, right? Like that

being my own IC work and kind of doing things that way. You know, as a VP or a director, my work is more strategic and throwing the gauntlet for other people to do some on the ground work. And so I think both are really exciting. And you kind of need, it's not like you need one with the other, but like it's hard to be a really good manager without having some of that IC background to understand, you know, what the problem space is and things like that. The area that I run is very technical. And so you kind of can't do that kind of work without having coming in with some understanding. But at the same time, as a manager, like, you have to have appetite to make things better. And I think that that is the one thing that is consistent across all these jobs is whatever I was doing was pretty outcome driven to like, I'm going to make things better. I'm either going to make things better via my, you know, coding all day, or I'm going to make things better via doing a lot of open source or enabling other people and ramping them up. I'm going to make things better by, you know, setting up the organization in a way where people can not have

distractions and be able to understand the strategy of their work. Those are all just different vehicles to an outcome. So I would say if people are interested, if people are nerds, and they're interested in these kind of roles, keep making things better. Like people do eventually see that, right? Like if you're jumping in and you're reducing chaos in the system and you're trying to make things work better, it doesn't always happen. But, you know, hopefully that is what people are looking for in folks and what people will support. Wise words indeed. So this book is for the rest of us. And in the abstract, you're talking about how engineering managers and leaders, a lot of us study for years to become great engineers. And then

we have this deal where as a great engineer and individual contributor, you're killing it, you're having great outcomes, right? You're good at your job. And then you get elevated inside of the organization to something that's entirely different. This is known as the Peter Principle, right? As people tend to get elevated to a place of their incompetence, something along those lines, where it's like, well, I was really good at one thing and that got me a promotion to this other thing. And it's kind of a natural progression, but the job is different. I haven't trained for this. Maybe I've never done it before. We know some people go to engineering manager and then go back to engineer again. We've done

a show on that topic as well, like finding out this isn't for me. I don't think it's about the Peter Principle. Oh, it's not? I think the Peter Principle is something else. I think the Peter Principle is talking about incompetence and leadership and that the book isn't really assumptive that people are incompetent. The book is talking more about that you do make a lateral shift from like, you know, a lot of people's trained to be like you're saying people trained to become engineers

and they get moved laterally or they get promoted into leadership. But I wouldn't, Peter Principle is more about people who shouldn't have the job that they have. I don't think that that's what this book is about. This book is more about like people who are really capable but need some tools in their tool set in order to get the job done appropriately. Like we've all had bobblehead-y bosses

who are not the best. Sometimes that's more like your principle in my mind. Okay, okay. We may be just interpreting that principle differently. I think we're on the same page with regards to you now have a new position that you're not used to doing or you haven't done as much. You need the tools.

And so you need either to learn how or to find out via experience. And the set of things that you're doing on a day-to-day basis, they change somewhat dramatically, right? So when did that first happen for you? Were you at Netlify at the time or were you at Microsoft? Oh no, I've been managing much longer than that. Yeah, I don't know if you've seen Charity Major's blog post about the managerial pendulum. It's a really good article about how sometimes people like to do IC work.

They get burnt out on feeling like they're not moving bigger needles forward. Then they go to management. Then they get burnt out on not coding. Then they go back. I'm kind of like that because I know how to do this managerial pendulum. I think my first lead role was probably 15 years ago, maybe more. And then went back to IC work because I really wanted to be in IC. I think my first lead role was probably 15 years ago, maybe more. And then went back to IC work because I really wanted to be in IC.

And typically what happens with me is I love to code. And so I'm attracted to doing like coding kind of work. But then sometimes I get frustrated if strategies are not getting unblocked or there's chaos in the system and my code can't do things that are good for the organization because it gets mired in bureaucracy and crap and face. So then I move over to management or if somebody puts me in management, sometimes like at Microsoft, they started moving me into management more towards the end of my tenure there because you know thing i was helping fix things like we were mentioning before um i didn't really want to be focusing on that at that time and then the vp job at netlify you know i talked to matt and chris about that role and we could they let

me design that role which is kind of unique which which was really great. And that was a really compelling offer to be able to like design what I wanted in a job. But yeah, I think I kind of go back and forth. What were the most challenging parts that maybe your first time into it, like when you came in, maybe when you sat down to write the book and think like, what do I need to equip people with through this book in order to succeed in this role. What were like the things that you kind of bumped your head up against? Yeah, I mean, I think like a lot of people, I went into management with no tools. Like I, the way that I entered management was through being a TL first, right? I had the more, I just was the most senior person on the project

and I knew the most about the technology. So I was put in a tech lead role. And then eventually that turned morphed into a management role, but like I have no training in management. I don't know anything about management. And so some of the book is a lot of like hard earned lessons. And that's why I wrote it was because I was thinking like, man, I've been at so many companies where I'm trying to teach other people one by one, some of these things that I stumbled through myself. We have like a thousand bajillion articles about how to's in code, but not that many about what you need to do to be a good manager. And, you know, it's hard on the people who are being learned on. All of the ICs who have managers who are just stumbling, trying to find their way, it's not through poor intentions, but people haven't given them tools.

So I thought maybe it could be a good resource for folks so that they can be better set up to support their teams. What made you want to write it? That. I mean, basically, I've, you know, basically I've written books before, so I know it's not about the money. Nobody really makes money on books. It was more about providing a resource that people could use to understand the base thing so that they wouldn't have to keep learning over and over again without, you know, something to grab onto, giving people tools that were kind of hard earned.

Love your opening up to the book. It's the very first chapter. I don't want to blow it for anybody reading or going to read the book, but spoiler, first chapter is caring for your team. I love that kind of reminds me to some degree of Rachel Popp. And we had her on the show, former director of engineering at GitHub. And that was kind of her thesis of managing and leading was it's 50% people and 50% like outcomes in which you can produce. But the first 50% was not the outcomes in which you produce.

It was the people. And it was you can't have a good team if they're burnt out. You can't have a good team if they have terrible relationships or anything like that and so i'm just curious if that's if that's how you feel as well and why you began your book with that chapter yeah absolutely you hit the nail on the head i mean caring for your team is like i mean basically i think sometimes people try to split up engineering culture and engineering productivity and it's they're one in the same. It is not two different things. If you like, think about the times that you're in IC, if you're not aligned to the mission, you feel burnt out, you feel underpaid that your boss

doesn't think about you like in, in a, you know, an understand your work, then you can't write good code. It's hard to write good code. And a lot of times when products don't work together, it's because those teams aren't talking together and they're not working together. Like we see this again and again, and people kind of shipping the org chart and the kismet between teams or productive staff do a really good job. And I think Nicole Forsgren, Jess Humble, and Kim wrote this book called Accelerate, which if you're not familiar with it, is a great one, which kind of proves this with data of going through these developer surveys. And what they

found was the teams that have more psychological safety to share mistakes, they feel more supported, things like that, they just produce more. And they produce better work, and there's less outages. So that one's an interesting read, just to kind of validate some of these things in a more data-driven way. Yeah, I do think that trust is really important at working together and cohesion is really important. And it's hard. It sounds super easy.

It sounds like, oh yeah, trust. But that's really hard. It's a very easy thing to destroy. It's a really precious thing. Well, that quote in there is just mind blowing. Honestly, it says trust is built in drops and lost in buckets. And that was a quote from the founder of Under Armour, Kevin Plank. I'd never heard of that quote until or read that. Actually, I didn't hear it. I haven't heard of that quote before I had read your book. And I was like, that is a phenomenal quote. I'm glad you included it, but it's just so true. It's like you gain it incrementally and you gain it over time. It's iterative towards trust,

but to lose it is just so quick. Yeah, absolutely. And that's why some of the chapters are like, you know, the first kind of fundamental chapter is giving people tools around values. Like a lot of that was probably the biggest tool in my tool belt, the thing that allowed me to work with different types of people much better. And I'm on a journey, you know, I'm not perfect at, I don't want to give the impression that because I wrote a book, I'm great at everything.

That's not true. But like, you know, that really helped me because understanding that people may have different values than you you and that's why they do the things that they do it makes sense to them allowed me to kind of have a framework to understand where people are coming from and we do you know values exercises in our teams it really helps you see where the person is coming from you're like oh you really value X. That's why Y is happening. Or like, I value this, and that's not the same as you. We both care about these things. It kind of allows you to

then find a way to align to similar outcomes without, you know, well acknowledging that you're not the same person. so in the sponsor minisode here in the breaks i'm here with tom who dev advocate at century on the codecov team so tom tell me about me about Sentry's acquisition of CodeCov. And in particular, how is this improving the Sentry platform? When I think about the acquisition, when I think about how does Sentry use CodeCov, or conversely, how does CodeCov use Sentry, like I think of CodeCov, and I think of the time of deploy. When you're a software developer, you have your lifecycle, you write your code, you test your code, you deploy, and then your code goes into production, and

then you sort of fix bugs. And I sort of think of that split in time as like when you actually do that deploy. Now, where CodeCup is really useful is before deploy time. It's when you are developing your code, it's when you're saying, hey, like, I want to make sure this is going to work, I want to make sure that I have as few bugs as possible, I want

to make sure that I've thought of all the errors, and all the edge cases and whatnot. And Sentry is the flip side of that. It says, hey, what happens when you hit production, right? When you have a bug and you need to understand what's happening in that bug, you need to understand the context around it. You need to understand where it's happening,

what the stack trace looks like, what other local variables exist at that time so that you can debug that and hopefully you don't see that error case again. When I think of like, oh, what can Sentry do with CodeCover? What can CodeCover do with Sentry? It's sort of taking that entire spectrum of the developer lifecycle of, hey, what can we do to make sure that you ship the least buggy code that you can? And when you do come to a bug that is unexpected, you can fix it as quickly as possible, right? Because, you know, as developers, we want to write good code. We want to make sure that people can use the code that

we've written. We want to make sure that they're happy with the product, they're happy with the software, and it works the way that we expect it to. If we can build a product, you know, the Century plus CodeCup thing to make sure that you are de-risking your code changes and de-risking your software than we've hopefully done to the developer community as service. So Tom, you say bring your tests and you'll handle the rest. Break it down for me.

How does a team get started with CodeCov? What you bring to the table is like testing and you bring your coverage reports. And what CodeCov does is we say, hey, give us your coverage reports, give us access to your code base so that we can, you know, overlay code coverage on top of it and give us access to your CICD. And so with those things, what we do and what CodeCov is really powerful at is that it's not just, hey, like this is your code coverage number. It's,

hey, here's a code coverage number. And your viewer also knows and other parts of your organization know as well. So it's not just you dealing with code coverage number and your viewer also knows and other parts of your organization know as well. So it's not just you dealing with code coverage and saying, I don't really know what to do with this. Because we take your code coverage, we analyze it, and we throw it back to you into your developer workflow. And by developer workflow, I mean your pull request, your merge request. And we give it to you as a comment so that you can see, oh, great, this was my code coverage change. But not only do you see this sort of information, but your viewer also sees it. And they can tell, oh, great, you've tested your code or you haven't tested your code. And we also give you a status check,

which says, hey, like, you've met whatever your team's decision on what your code coverage should be, or you haven't met that goal, whatever it happens to be. And so CodeCov is particularly powerful in making sure that code coverage is not just a thing that you're doing on your own island as a developer, but that your entire team can get involved with and can make decisions. Very cool. Thank you, Tom. So, hey, listeners, head to Sentry and check them out. Sentry.io and use our code changelog. So the cool thing is, is our listeners get the team plan for free for three months. Not one month, not two months, three months.

Yes, the team plan for free for three months. Use the code changelog again, century.io. That's n-c-n-t-r-y dot i-o. And use the code changelog. Also check out our friends over at CodeCov. That's CodeCov.io. Like code check out our friends over at CodeCov. That's CodeCov.io. Like code coverage, but just shortened to CodeCov. CodeCov.io.

Enjoy. So what do those values exercise look like? You just ask everybody what their values are? Is it more complicated than that? Yeah, there's a couple of exercises that go through in the book. One of the values exercises is just that, you know, you put a bunch of values on the board, you ask people to pick three to five, depending on how much time you have. And, you know, you ask them to talk about the origin of those values, like what, what, what makes that a value. And as they talk through it, you do get a better sense of like, you know, I'll give a couple of examples without, you know, anonymous examples, somebody saying like, oh, well, you know, I need, you know, my, one of my values is my family. So I

really have to have work-life balance because if I don't create that boundary for my family, you know, then I'm not living my values, I'd burn out. And that can make it really clear why the person's not on after hours ever. And that's okay. Right. Like, and, you know, all the way to like, I value honesty and directness. And I, you know, my family was really strict and their form of kindness was to be honest. You don't care unless you are direct. And, you know, you can have someone else on the team who doesn't like confrontation and they value, you know, people getting along and, and things. And so you can see how things might not work with them at first until they understand that about each other. And so maybe that person who likes to move away from conflict learns to move a little bit more towards it. Person who, you know, likes the conflict knows to be a little bit more gentle with the person who likes it. Like, you know, we're not trying to make a world that fits everyone. It's not possible, but just to understand each other better and so that we can work together more

easily. Going back to the trust thing for a moment, trust is tough. Like you said, Adam, or like the Under Armour guy said, right? Kevin Plank,

yeah. Kevin Plank said, it's about, you build it in drops, right? You build it kind of step by step, but in the, in business life and I'm sure in management as well,

like you, you hire a new person, or maybe sometimes somebody else hires them and says they're on your team now, right? And you're like, okay. And you just met them. Maybe you have some history. Maybe you have a little bit of a rapport, but you don't know them all that well. How do you deal with trust in that circumstance?

Like what's the most adaptive way as a manager? Do you give the benefit of the doubt until proven otherwise? Are you somewhat, you know the benefit of the doubt until proven otherwise? Are you somewhat kind of like, eh? Because there are certain people that tend to be more skeptical or more less trustworthy by default. I tend to trust people too much sometimes until they burn me. And I just wonder, is there a right way? Is there a better way when it comes to leading teams? Well, I think trust is something that's built incrementally over time. As you mentioned, I do think that you have to give people benefit of the doubt and kind of try to see things from their perspective and building things. But you can also set up the initial parts of that

engagement by asking questions that build trust together. Like, what do you value? What motivates you? What are, you know, like when you're first kicking things off, how do you like to get feedback? Just things that can help you understand the person so that you're not like, do I trust them? Do I not? And by keeping that also consistent, keeping things consistent across people is really important because human bias is just a thing. Like there's just study after study that we all have biases. It's just who we are and how it works. So if you're going to try to eliminate or reduce by, you can't eliminate, but reduce bias as much as possible, keeping a consistency allows you to not treat one

person different than another. Cause humans do tend to, you know, like people more that they are more like, and you don't want that in a team, right? You want to give, you don't want to make people feel excluded by accident. And so if you can try to set up the same kind of systems of building trust with people and keep it egalitarian or as equal across boundaries as possible, then at least you're starting from a from like a base that's kind of the same across people as much as you can. That's probably even more difficult times, I guess, you know, post-pandemic or during the now after where we have way less data, you know, with regards to our relationships and our teams. We have way less bandwidth, right? Even us here, we can see each other's faces,

we can hear each other's voices, but it's a... Yeah. It's a pixelated rendition of who we are. And, you know, it's hard to get to know each other via these channels and Zoom calls and whatnot. Have you found it in your teams and in your work and maybe even manifested into the book, you know, ways that you can overcome, you know, some of these drawbacks of digital communications?

I actually see it a little differently. I don't think that we have no data, but I think I've been a remote leader for many, many years, even before the pandemic and remote leadership takes extra time and care. Like you're saying, there's that kind of pixelated things on the screen where you're not building quite as much trust as in mirror neurons that you are when you're in person. That's why in remote leadership before the pandemic, you saw each other in person, right? Like you would meet once a quarter or something and you'd get to see each other. And then some of the trust that's built there can carry on. But remote leadership isn't the same pre-pandemic and during a pandemic. And I think the things that

were different, one, everyone was terrified. Like no matter who you were, you were dealing with this massive issue that was going across all these different boundaries. People had different that were different. One, everyone was terrified. Like no matter who you were, you were dealing with this massive issue that was going across all these different boundaries. People had different thoughts and opinions about it, but it was happening to all of us at once. That was, you know, on people's minds. That's very different than normal life. Not being able to see each other in person ever was really hard. And then I think remote teams before the pandemic also did, you know, took certain steps to make sure we had async hygiene set up, that we knew when people were working, when, like that we were passing batons between. And everyone during the pandemic was just kind

of thrown into it. It wasn't like, this is what we're going to do, and this is how we're going to do it, and we're going to set up a system to make this successful. It was like, ta-da, you're remote. And it's not, it wasn't necessarily something people opted into. It wasn't something people necessarily thought about building a system around. So we're seeing a lot of variants, or at least like I run, you know, you know, my org has many teams. Some of them are remote, some of them aren't, and some of them are hybrid. And you can see there's differences because some people care more about async hygiene and setting those things up. Some people kind of fell into it. Your mileage may vary depending on the way that it's executed. Some of the methodology is important, too. I was digging your chapter on change. I like change, but I don't like change. I was surprised when I read it. I didn't see a mention of whom I choose, which is like the quintessential book to point to when it talks about change.

But you did have another awesome quote that opened it up. I'm going to read it if you don't mind. It says, this is from Charles Darwin. It says, it's not the strongest or most intelligent who survive, but those who can best manage change, which basically is resilience, right? Like if you can adapt and maneuver around this, and this is kind of like to some degree hedging off of the pandemic, because like we all had to change pretty quickly and adapt pretty quickly. Can you speak to what you've learned around change management and resilience as a manager and how you help people and groups through, I guess, massive change like that? Such a great question. Yeah, I agree with you that it is resilience, right? Like

it is building resilience to change. Some change happens because if you're at a big company, some change happens because other people decide things that you're not in control of that you then have to own somehow. And then, you know, sometimes change happens because you see a need for the change to occur. In all cases, usually the trick, the biggest trick, there's not just one and your mileage may vary on different situations, is aligning people to the reasons why the change is occurring. It's really hard for people to internalize and move towards a change if they're not aligned, if they're not talked down to in that process, if they get a bunch of corpse speak, if there's ambiguity. You're causing people stress and they don't know why that's an awful situation for really smart people, which, you know, your teams usually are really smart. So they're deserving of that kind of trust that

you're unpacking things well. And so there's, there's some transparency, there's some, you know, alignment on why things need to be the way that they are. But, you know, it also is, can be quite chaotic if there isn't good information flow, like, you know, some of the chaos that I've seen and done, because I make mistakes to all the time is not aligning, you know, a smaller group of stakeholders first, and then rolling things out. Like if information is uneven, or, you know, let's say you have multiple partners, like you usually have eng, PM, TPM, let's say like those top level people aren't all aligned as a change is rolling out. That can be really confusing if they're hearing one thing from their PM, another thing from their engineering

lead, like that happens, that happens a lot, especially at scale. And so that, you know, that kind of changes like aligning first in some groups and then rolling out information and decisions to lower and lower level that, people who are smart at the kind of engineering management layer will be like, hey, did you think about X? And you're like, oh, I did not. So it's not just making sure people are bought in, but it's actually being open to maybe you shouldn't be making this change. Maybe there's something you didn't think about. Giving a moment and time to address some of the feedback at every level. It's a hard thing. I'm making it sound easy.

It's actually really, really tough to keep people aligned or even keep things open enough that people can address and then close it down so that people know a decision was made. How many people are you inside your org generally? Around 120 I think but with cross-functional partners as well. Do you ever have to say like that's it

we're all going to get into a room like digital or otherwise we need to figure this out or do you speak to the managers who speak to their teams? How does it work? We do have all hands every quarter so that's like bringing you know, I bring everybody together.

Like we just did, you know, we were working on like this, you know, 10 year strategy. We rolled that out to the team like this last time. But even in that one, we aligned at director level, then leads level, then engineering and engineering managers and TL level level than the whole org so by the time we did the all hands you know people had a chance to raise their voice bring things up like we kind of and we change things during the process like we would do we would read people in they bring things up we'd iterate we find you know find either better ways of thinking about the problem or better ways of communicating, you know, yeah, it's 120% work. So it's not like coming together to be like,

this is what's up. It's more like, hey, this is our, this is where we're thinking about going. What are your thoughts? We open up a thing called Dory so that people can put questions, even if they're anonymous, so that we can talk about the hard stuff, you know, and people's concerns. I do think that, you know, it's a sign of health when you address concerns, not when you push them down and pretend they're not there and, you know, try to be as open and open to follow-up calls and things as possible. But, you know, in between those orders, I do meet with my directs and our cross-functional leadership once a week. We also have the thing called topicals where we go over a certain topic for an hour long. Like one of them is more of like a status thing and the other one's

kind of like digging into like, how are decisions made on our team? Or like, you know, other kind of things that can kind of keep us healthy. And then we do have a manager cabal and a TL forum for those groups too. So top-down change, we've been speaking about. What about bottom-up change? Like what about empowerment or people, you know, ICs feeling like they can affect change

or how do you make avenues and make that something that can happen so that people feel like they're not just being talked to? So Google is a very bottom-up culture. Almost nothing happens top-down. That web strategy is a really strong exception. The majority of the things that we do on the team do have genesis from the team. It is the team deciding what they're doing, bringing it up and saying, I think we need to go in this direction. Every once in a while, for some teams, I do come in and throw gauntlets.

What I mean by that is to say, okay, we're going in this direction. I'm not sure about it. Maybe you're right. Maybe we need to go in this direction, but I need this validated. Like you have to defend this for the next 10 years to all of our stakeholders and customers and partners like across YouTube and Gmail and search and everything. Tell me why.

Why is this the right direction? And have you considered this approach, this approach, this approach, this approach? I would love for you to set aside some time and explore that. So they set some time aside, they explore it, and they come back to me and they're like, this isn't the right direction. We should go in this other direction. I'm like, cool. But I'm not telling them go in this other direction. I'm saying like, you tell me,

but I just want you to really do the homework here. Or sometimes I'll go to really like do the homework here. Or like sometimes I'll go to teams like the Angular team and be like, hey, you know, you don't have to do this because I want you to, but like have you thought about X, Y, and Z? Like it feels like there's something to be discovered here. And they'll come back and they'll be like, there is, and we're going to do X. So like, you know, the teams are pretty empowered in that way. But, you know, sometimes I give feedback or throw gauntlets.

I use the term throw gauntlets a lot. I love gauntlets. I like that term, throw gauntlets. Especially as somebody like yourself who likes a challenge, right? Like when someone throws me a gauntlet, I'm like, all right, here we go. Yeah, because if you feel trusted

and empowered to do it, then they can come back to me and be like yeah or stick it stick into the course you know whatever yeah right right or even just being able the question i think you asked in this example the gauntlet at least was defend your position and can you do it for the next 10 years like if you have this conviction for x y or, or Z, whatever that might be, consider the stakeholders, the customers, and the next 10 years of these products, how they'll change or be influenced by this non-change. I think that's pretty powerful because it's like, well, that gives them an opportunity to go and re-examine their thoughts and their feelings, maybe re-examine their data that's already informing their decisions, and then come back to you and say, you know what, Sarah, you're right.

This could be a good direction, but because of this, this, or this, these are the reasons why. And as a manager, that got to make you feel good, right? Like when somebody can go and give you that firm foundation, because in a lot of ways, as a manager, you're not providing the foundation necessarily. You're providing the opportunity for the foundation and it's the ICs and those who are the doers that are kind of putting that foundation down. But you get to then stand up when you say to your bosses and their bosses saying, hey, this choice was this reason or for this reason, and I have a firm foundation because of this data.

That's got to make you feel pretty good. Oh, yeah, absolutely. And it creates alignment up and down and around. I think what we can't do is ship our opinions, right? We're too high scale and we serve too many people to say like, I like X, so we're doing X. That can't be the reason why we're doing things. We have to gather requirements for customers. We have to think like engineers. We have to be really diligent and methodical about the way that we think about these things, the way we solve problems.

And so we have to kind of check ourselves and move ourselves away from strongly held opinions as much as we can in order to do that work. And, you know, they're smart. They are closest to the problem. So, you know, definitely don't, you don't want to get in the way of intelligent people who know the space. You just kind of want to guide the conversation a little bit because sometimes when you get really close to a problem, that's all you can see. You kind of have to encourage moments in time where they can zoom out a little bit and, you know, kind of reconsider things. Like

I'll give another example. Our build serve process in Google is very different from the outside world. But what I asked that team was like, look, you can't use the outside world stuff. I get it. But the parcel web pack, all of these innovations and external have been, you know, ES built, have done amazing things for a good reason. Take some time and, you know, reverse engineer and, and tell me what you think. And they came back and they're like, yeah, we can't change our system, like move it to this system, but we just discovered a bunch of passes that we don't have to do that could save us X, Y, and Z in these performance benefits. Like that's amazing. Um, And it doesn't necessarily mean that they're going to change their whole trajectory or anything. It's just being open to, you know, other things.

Right. Steal some good ideas. And sometimes you take a good idea and you don't take it. But you're like, I just know that now. And it may come in use down the road. For sure. And that's super powerful stuff. You said, though, we can't ship our opinions.

I tried to search quickly on Google, and I can't find anybody who said that before. Is that a Sarah thing? Did you make that up? That's phenomenal. That's just me. Just now, or you say that a lot? I don't think I say it a lot. I might have said it internally a couple times to people.

We can't ship our opinions. I mean, I love that. That's so true because that's got to be great to have as a tool, as just words, as a manager because that's so true. If you have an opinion, you can't ship the opinion. I don't want to restate what I said before, but the data and the foundation, et cetera, you can't give just the opinion and be like, well, that's how I feel, and so therefore we should just ship it, right? But that's pretty profound. I like that. I was going to say, Adam, isn't that what you and I do? We basically ship our

opinions, don't we? Well, we're different. Yeah, we are. We're different. I know. We're not the common product, you know what I'm saying? It's like that one episode we did, You Are Not Google. Remember that one way back in the day? Yeah. We are not Google. So we can ship our opinions, but your mileage may vary. Right.

Yeah. I mean, I think all of this stuff is your mileage may vary. I try to give that caveat in the book a lot, that I've worked at startups. I've worked at big companies. I don't use the same tools for both of those jobs. They're quite different. And yeah. Right.

That's actually a real stumbling block, it seems, for many engineers and teams is kind of taking big tech solutions to their small tech problems or just misapplying things and saying, well, it works for Facebook, so it'll work for us. And it's like, eh. The thrust of that show we did years ago with Oz One,

you are not Google slash Amazon slash whoever else is because I think even maybe it was LinkedIn. I don't know. Just because, you know, different tools and different solutions don't fit every single scenario. And so like we need to evaluate and apply engineering thought, right, to decide what's going to work in our circumstance. And, you know, you can read Sarah's book and probably get lots of tools and interesting things out of it. But then you have

to put it through its paces and see how it's actually going to help you or not, given your context, because Sarah didn't have your context necessarily when she wrote it. That is 100% correct. Yeah, I completely agree. And it's trying to say that a couple of times that what works for me exactly won't work for you exactly. And yeah, you hit the nail on the head that engineering is a lot of it depends. It really is. There's nothing in engineering usually that is without trade-offs.

And so you have to always consider if you're making the right trade-offs for what you're doing and for your own team. And I don't have every experience in the book in the world either. So you may have a different experience than me. So it sounds like the whole it depends thing applies just as much to management as it does to engineering. For sure. Although I think yes and no, like just like in software engineering, there are some things

that are true-ish that could be applied to many things, right? Right. But like there's software that can be very brittle that you probably don't want to write. And I think that there's stuff in engineering like that too. Like there's a lot that, and I think the book does try to generalize the things that are a little bit more, you know, the stuff that could be useful for more people. There's a bunch of chapters where your mileage may vary. Like I talk about what it's like if you try to prioritize between PM and projects and things like that, that that's very, your mileage may vary. That's just in case you

don't have a process set up or, you know, things of that nature or like setting up your calendar. I don't know. You can set up your calendar however you want, but here's some things I do. Right. But there are things I think that you can't not do. There are some things that I see managers mixing up or forgetting about or losing the forest for the trees on that I try to cover in that. Like just even the general idea that you should be making things better, that it is your job to solve problems. Sometimes people forget that. People get wrapped up in the power parts

and forget the responsibility parts. There are also things that you probably can't not do, like supporting your team in their careers. I have definitely talked to managers who are like, wait, you have one-on-ones? I'm like, you don't? Why aren't you having one-on-ones? So I would say having one-on-ones? So, you know, I would say having one-on-ones

is maybe not a Sarah thing and maybe more like you probably should be doing that. Yeah. What does that look like exactly? Well, what it looks like exactly, like how you set up your one-on-ones can depend on the person. But the idea that you meet with your staff

and meet with them alone and talk about your careers and talk about their, your careers and talk about what's on their mind and what they're working on. I think that probably all managers should be doing. I don't take that many strong opinions, but that's, that's probably my strong opinion strongly held. How often should that happen? Well, that's where the mileage may vary part, right?

Like I, I have seen people at startups who have like 15 direct reports, which I think is way too much. That's really a lot, you know, beyond eight to 10, it gets really hard. If you have that many direct reports, then you're probably not seeing people quite as much. But what I try to do is keep under eight and meet with them every week. And the length of time depends on how much trust is built and what's going on, right? Like when I first joined Google, I had hour longs with every single person on my team so that we could get to know each other and we could build trust and we could see each other for a little bit longer and I could get to know what they're doing. Over time, some of those decreased to a half an hour a week if things are just humming along. I have multiple people on my staff that they're just doing a great job.

We can share FYIs and we can talk through things for their careers, but I trust them. They do a great job. And sometimes I have longer one-on-ones. I have a Uber TL and T and I have tons to talk about. We run out of time on our longs every week because there's so much going on in the org that the two of us have to collaborate on and make sure that we're driving and executing on. So it kind of depends. Hey, friends. This episode is brought to you by CIQ, the founding sponsor and partner of Rocky Linux, Enterprise Linux, the open source community way. And I'm here with Gregor Kertzer, the founder and CEO of CIQ and the creator of Rocky Linux. So Greg, I know that a lot of people are still sort of catching up to some degree with what went down with CentOS,

the Red Hat acquisition, and just the massive shift that required everyone using CentOS to do. Can you give me a glimpse into what happened there? We've seen a number of cases in the open source community where projects were pivoted due to business agenda or commercial needs. We saw that happen with CentOS. CentOS was one of the primary, one of the biggest enterprise operating systems ever. People were using it all over the place. Enterprise organizations and professional IT teams were all leveraging CentOS. For CentOS to be stripped away from the community and removed as a suitable option to meet their needs created a massive pain point and a gap within the industry. As one of the founders of CentOS, I really took this to heart and I wanted to ensure that this does not happen again. And that is what we

created with Rocky Linux and the RESF. Okay. You mentioned the RESF. What is that? And what is its relationship to Rocky Linux? The RESF is the Rocky Enterprise Software Foundation. And it is a organization that we created to hold ourselves responsible to what it is that we've promised that we're going to do with the community. It is community run. It is community led. We have a board of directors, which is comprised of a number of people that have a huge amount of experience, both with Linux as well as open source and community. And from this organization, we solidify the governance of how we are to manage Rocky Linux and any other projects that come and join in this vision. Sounds good.

Great. I love it. So enterprise Linux, the open source way, the community way has a home at Rocky Linux and the RESF. Check it out and learn more at Rockylinux.org slash changelog. Again, rockylinux.org slash changelog. When you do those one-on-ones i suppose it may change over time but maybe give me a version of initially and then maybe over time but do you structure them in terms of like you have particular

questions or certain hit points did you go against or do you just do a lot of listening how do you you know move along that that path great question. Yeah, I have a standard doc that I use for the first one on one that asks things like, are you happy with your career here? Yes. Why or why not? It starts with intros, of course. What do you do outside of work for fun? What motivates you? How do you like feedback? What's your biggest blocker here? I have a bunch of questions like that. And I tell them straight up when we join the call, this is your time. We don't have to talk about any of these things if you don't want to. I put these down for everybody and it's kind of useful to understand these things about each other,

but this is the first time we're meeting. We don't have to talk about this. We can talk about whatever you want to. So from there, it is a lot of listening because they're either going through the questions or they're telling me something that's been on their mind for a really long time that they need solved or something. Or they're telling me about something that's very important to them. And there can be times in coaching where you're listening and there can be times in coaching where you're giving advice. I tend to ask people which one they want because sometimes people just want a vent.

And sometimes people want my perspective. And sometimes I coach via questions because they might know the answer internally to them. And I want to bring out that answer just like what I do with the TLs. Why is this an issue for you? Why do you... I had somebody who was like, I don't want to go for promo. I'm like, why don't you want to go for promo? And they talked through something that bad that happened in their life and, and things

like sometimes asking why is part of the discussion too. I tend to be a jump in and fix it person. So I gotta be, I always have to be really careful to not do that when people don't want that. Do you feel like you're a pseudo therapist sometimes in this position? Yeah. I mean, sometimes, but not for, I think most of my work is technical and then every once in a while people don't get along and I have to help. So only if necessary. I don't think I make a good therapist. I'm not.

Whether by choice or by force is kind of what I meant by that. It's like sometimes you're sort of, by nature of the job, you're forced into it. It definitely happens, for sure. Yeah. Okay, do you have any other can't nots?

Because you said one-on-ones as a can't not. You also seem pretty hardline, eight to 10 direct reports. Don't go over that if you can avoid it. Are there any other like kind of rules of thumbs or things that you're like, you know what? I have strong opinions about this

is pretty much the right way or the wrong way of doing something. Oh, good question. Trying to think. I think you have to align people to why. That is a really important one. I think most of the time that people get really bogged down or they don't believe in their

leaders or trust problems happen, it's because people aren't aligned to the outcome. They don't know why they're doing things. They think that leadership is hiding something or there's some sort of ambiguity or there isn't transparency. If you build, the thing about, you know, that I think leaders get worried about is that people won't trust them if they are more honest. I think the opposite happens. Like if they don't act like a commanding force, then that people won't respect them. I think actually respect happens a little bit more. Like people can definitely pretend to be aligned when they are fearful, but I don't actually think that people do their best work in fear.

I don't tend to agree with that. Can't not. So that do their best work in fear. I tend to agree with that. Can't nots. That's a good question, Jared. I like that. So that's it. That's the end of the line for can't nots. You were on a roll. I love them.

Align your whys, one-on-ones, and not too many direct reports. So if you're doing those three at least, then you're off to a good start. You said most of your work is technical. What do you mean by that exactly? Well, most of it is trying to. What do you mean by that exactly? Well, most of it is trying to figure out what we need to build, why we need to build it, meeting with customers. To make solutions that our team does for all of the problem spaces that Google has, we call these PNs customers, like gmail.sheets, that's workspace, that's one. YouTube is another.

Search is another. Ads is another. Pantheon, which is Google Cloud Console, is another. In order to make solutions that fit all of those massive PAs and all of their distinct needs, we have to be very, very diligent about collecting what their needs are in the requirement space and understand the restrictions of our own technology tech debt and things like that in order to solve those problems for our users. And that is technical work. That is not something that you can do by being hands-off you have to kind of dive in you have to ask other kinds of questions i mean we're all engineers so people love to come with solutions to problems without even understanding what the problem is and so we have to kind of work together on on building what's right and that can be that can be really hard and so that that's that's the majority of what I do.

How much do you get into the weeds or how much are you hands-on with regards to process? Like when we go into individual engineering teams, how they go about accomplishing the goals that you all have agreed upon going about? Are you in there on the weeds in that or do you just stay out of it? I'm mostly letting teams self-organize around what they want to be doing. Every team has different needs and things. We are trying to create a little bit more consistent process for understanding the broader portfolioServe works. It affects the way SaaS works. All of our teams need to be at least aligned on that. That is a high priority and that we all need to get it done together. We have some things that are process-oriented to prioritize our work together, to understand

what people are working on, where the risks are. We have processes in place to understand where things are for strategic customers, whether they're're red yellow green and in terms of status and things like that so we can right and collaborate well but no in terms of the like the very distinct house i trust them there's your trust again comes back to trust so these processing tools are these like internal like kanban board style things are just like generally speaking like that kind of a tool that everybody uses to see where the status of certain things are i'm assuming yeah we have some internal tooling for that just like other companies too all right so we got the can't do we got the can't not you have to do these things what about things to avoid like don't do this this is this is a fail every time. Trust me, I've done it before. I tried it.

Doesn't work very well. I have anything that people can avoid. Yeah. A big one that I had mistakes of early in my career and continue to probably, because I used to be an IC, and we just talked about trust. One of the biggest mistakes I had was diving into do it myself. Like sometimes it is faster if I write the code myself because I know how to get it done. And more fun. And the truth of the matter is, and this was especially true when I was switching. And the truth of the matter is you have to teach people on your team. And sometimes it will take longer for them to learn and things. But you're making an investment in them and you're helping them learn so that they can be empowered for the next

time and stuff. And some of that is even protection. I'm kind of a mama bear and I want to protect my team. These are great humans who are thoughtful and productive and wonderful. You want to protect them. But I have learned over time that you can protect too hard where you don't allow them to grow. There was a person that I was trying to get promoted, and I protected them from all sorts of cruft and politics and things. And then when I left, they had no tools to deal with any of that stuff. And I really didn't set them up well because I protected them too hard. I should have been still protecting them,

but maybe teaching them along the way so that they knew how to navigate it when I was gone. Another example of this is, you know, just in tech kind of things, like I'm sad to say, I've been the manager of teams where I had so much of the infrastructure and I built so much of it that when I left, they were like, what is this? That's not good. You know, that's, that's a lesson I had to learn for sure. So, you know,

some of it is about learning myself how to empower people instead of like fixing everything myself. Sometimes out of very good intentions of like wanting to protect people. Or sometimes I'd protect it so hard that I wasn't letting my peers in. Like you protect so hard that you aren't being a good partner to everyone across all of your peer landscape and driving towards more common company goals that you need to all be collaborating on. That's not a good partnership. You're working at the same company they're not against you right um so like i i had to learn to like you know not let go of mama bearing you have to have some protection of your team that's part of your job and caring for them but not holding it so tight that they weren't able to do to function well or learn or grow or

work with other people there's like a tough balance to strike. It seems like one that maybe you almost can't learn until retrospect, at least the first couple of times. Because how do you know when it's too tight until you look back and you're like, ah, that was too tight. Yeah. That's right. Well, I definitely learned it through mistakes.

Yeah, that's how you learn. What about self-management? The last part of your book is kind of like tactical in terms of like how do you deal with you not anyone else but how do you take care of you there's a chapter in a book i like to read and i reread it it's a it's called essentialism so sir if you've read it before let me know but there's a chapter in the book that essentially is called protect the asset and that's kind of how I would summarize part four, your work. It's kind of like protect the asset.

Can you maybe pick some favorites from that section that are your favorites in terms of protecting the asset and managing yourself? I love that. Actually, I don't know the book Essentials and I'll go look it up. It's amazing. That's cool. Yeah, you're absolutely right. It is protect the asset.

You cannot be a good leader to your team if you're not taking care of yourself. And taking care of yourself can mean something like managing your to-do list and making sure that you are working on the highest priorities for your organization and not just reacting to chaos. Because it's always going to be a little bit chaotic. The more you grow, the more chaos there is. So you have to kind of figure out in this wide bucket of things you could do with your time, how are you going to spend of figure out in this wide bucket of things you could do with your time, how are you going to spend your time that's most effective and that's going to be most strategic for your organization. You can't do that unless you have a good process to like understand

your work, understand what's still open that you haven't closed, understand what day you're doing what thing. So there's some of those processes in there that are kind of tactical. And again, other people can have other systems than me. My thought there is like, you have to have something in place to help you figure this out and to hold that information. You don't have to use mine. And then other things are just keeping the oxygen mask on. There were times I was overworking so much that I wasn't seeing my family and my friends and things. And I started getting really bummed out. Guess who's a bad leader? A bummed out person. You do have to like, you know, I kind of tie that chapter a little bit with boundaries. Because in order to take care of yourself, you also sometimes have to make boundaries where you, you know, understand what your,

what your values are, protect them and make sure you have time for the things that give you, that fill you up. Like another example of this is I exercise. I don't actually exercise to keep myself fit. I mean, that's nice, but like I exercise because I know I have better mental energy and then I have more to give. I have better capacity when I exercise. I know I have better mental energy and then I have more to give. I have better capacity when I exercise. I just get those endorphins from running and that allows me to be a little bit more open to people. The days I skip exercising, I can actually tell. Like I can tell that I'm not showing up for my team quite as well. And that might not be true for you. I'm not saying that you have to go exercise. I'm saying, like, figure out the stuff that you need. That's going to be very particular to you. Maybe you like really want, you know, a certain walk on your way to work because that helps you clear your mind and stuff. Maybe you need to like spend an hour on Reddit so that you can just goof off and have some time to yourself like whatever that

thing is uh make sure you're doing right truth everybody needs a distraction sometimes they're healthy and sometimes they're maladaptive you know so true that's the the filling your cup chapter i enjoyed that one because it's like you know you can't you can't be you unless you're you right like if you don't take care of you're you, right? If you don't take care of yourself and you don't find a way to fill your cup and set boundaries and say no to things that should be said no to and define all those things for yourself, if you can't self-manage and self-regulate, then you're no good to anybody else. Here's a related question. Maybe you guys can both answer this one because I struggle with this. How do you know when to say no to something or somebody and then how do you actually say it that's a great question

that's one i had actually had to go to therapy before okay like i'm really bad at saying no i just did not i did not i was not raised to say no to things um so I still think it's hard. I do think that one thing that can be challenging is that people, there are not everybody, but there can be an expectation that you say yes to everybody and that your time is available for everyone. Doing audits, one thing that I did that I think I talked through in the book is I write four buckets of my values, like the things that I want or that I think are important. And I put those buckets and then I write four buckets of my values, like the things that I want or that I think are important. And I put those buckets and then I write down all the things that I'm doing. And then I put them into the buckets and things that cross over many buckets or things I keep.

And the things that are in one bucket or in no buckets, I go like, okay, it's in no buckets. Why am I still doing this? Why am I doing this thing? Yeah. Yeah. That's a good move. Key objectives. I like that. Saying no is hard, Jared.

I know. You know, my problem, I think, with saying no, and it is, we said this on the podcast we have, Sarah, called Brain Science. And so it's myself and somebody way smarter than myself. She's a doctor in clinical psychology. Her name's Muriel Reese, Dr. Muriel Reese, to those who really want to get formal. But we did a show called Your Choice is Your Superpower. And so that's essentially what Jared's asking here is like, how do you say yes or how do you say no?

And that's challenging because or even to know really when to say no because there's times i've wanted to say no and i reluctantly said yes and i and i went into it reluctance and i got into the situation or whatever it might be and i learned and i stretched and i grew as a result and even though i didn't want to was uncomfortable to say yes i wanted to say no i'm thankful i did say yes that's what makes that's what makes saying no hard. But then there's other times where the exact opposite thing happens. Exactly. And there's other times when I'm like, I said no. I felt very convicted for saying, you know, I felt great conviction for saying no. And then I'm so thankful I did because,

wow, dodged a major bullet there. So it's just really tough to know when to say yes or to say no. There's also a scale element. I think that there was a point in my career and maybe for yours too, like we'd love to hear from both of you about this. But there was a time when I had limitless time and I could say yes to everything. And I didn't have many requests for my time coming in. In fact, I was hungry for more.

And I started engaging open source and I was really hungry. What can I work on? I want to work on everything. And then you get to a certain point, especially with open source, where the requests or the volume of requests are way bigger than the amount of time that you have. And that's when this starts to become more of an issue. Because yeah, if you start saying no too early, then you miss out on all that great growth that Adam was just talking about. Like you don't want to, you know,

say that you're creating a boundary when you're really just like protecting yourself from learning. Like you're scared even, you know, you're scared or something like that. And at the same time, like I'll be honest at this scale, if I added up the amount of requests for my time a week, it would probably be, you know, 400 hours. I can't do 400 hours of work in a week. So I have to be careful about my time now in a way that I didn't before.

I think it's kind of very clear on the high scale spectrum and very clear on the low scale spectrum and really hard in the middle, or that's when I went to therapy. Well, you know, you bring up a good point though with therapy is that you do need somebody to bounce things off of. It could be a legitimate therapist, but some people, they think well by thinking out loud and it doesn't become true or become concrete. They need to speak. They need to talk it through. They can internalize it and it doesn't become true or become concrete they need to speak they need to talk it through they can internalize it and it could be a therapist it could be a really good friend it could be you know a close boss or an adjacent co-worker whatever it might be find

somebody that is out there that can be that confident to you but just talking through things can be very powerful and some people literally need it to really concrete the things that are in their brain and how they feel. Yeah. And also there's a little bit of tough love element in there. You need somebody who can, if you are going to go with someone else and do rubber ducky kind of things, you need someone who is comfortable pushing back on you lovingly. I needed that. Where I was saying yes to all these things and they had to feel comfortable enough saying like, you say you want to see your friends and your family and you're sabotaging that by doing X, Y, and Z. Only somebody who's really comfortable holding me

accountable and then in a loving way can help you sort that out and go like, oh, you're right. I totally am. And their job isn't to convict you and say, well, Sarah, you're wrong. It's just more like, hey, adjustments, like course correction, like a few degrees. It's not a 180 necessarily. Maybe sometimes it is. But in some cases, like, hey, reminder, this is what you said you wanted to do. But this, this, and this is leading you said you wanted to do but this this and

this is leading to not doing that and there you go y'all ask such great thoughtful questions i feel like i'm learning as much on this podcast get out of here sarah get out of here i doubt it but i appreciate that sentiment well sarah i was just gonna say i'm very very happy that you said yes to us yes to us. Yes. To come on the show. Thank you so much for having me. This has been a pleasure. Yeah, I appreciate it.

It's been a pleasure reading your book. Honestly, I feel like it's, you know, even for non-managers, it's still good too. Like I'm the rest of us, I suppose. I manage, who do I manage around here, Jared? Me? Mostly yourself, but also. Mostly me, right?

We manage each other. To some degree, yeah. We're accountable manage each other to some degree yeah we're accountable to each other for sure so you know small teams like ours which is like just basically jared and i plus you know a small cadre of contributors and full-time employees but it's not a big team it's not google right although you do work there and your experience comes from large organizations i've learned a lot from reading your books. I really appreciate you writing it. More than anything, you said early on that, I'm going to paraphrase to some degree, but just that you don't know all the things.

So some people might say, well, Sarah wrote a book, so she must know everything. I'm just thankful that you were confident enough to write down what you did learn because so often we don't do that we don't leave the breadcrumbs for the later us's the people that are inspired by us to follow whatever it may be and we may not be the most inspiring people maybe some more than others the point is you you took the time to actually write your thoughts down and put it down you threw the gauntlet down as you said before before. That's right. She threw it down. That's enough. And I think that one thing we do here as, I guess, for the most part, podcasters, sometimes therapists, sometimes great friends. I think we help people realize they have more power than they believe they have. And I'm thankful for people like you who wrote down so much before this book even, too.

Right. But you put so much wisdom out there and you put it out there for everybody to read and that is such appreciated i mean i really appreciate that thanks i really appreciate that you know it's a big labor of love so it's it's nice to know that people got something out of it you know it's a lot of time and energy and blood and sweat and tears to do stuff like this so like i'm i'm really happy that it's been useful for people and, and, and I really appreciate y'all,

you know, engaging and talking through stuff. You bet. I'll just add that. I really love the artwork on the cover. Yes. And to our listener, you can check it out.

Of course we'll link it up in the show notes, but engmanagement.dev. Is that the best place to send that? Engmanagement.dev. You can the best place to send them? Engmanagement.dev. You can see that artwork and links to Amazon as well as get a free chapter. So definitely, definitely check it out. Anything left we didn't ask you, Sarah? Anything left unsaid that you want to end with here on the show?

Oh, man. That's like such a good thing that I wish that I had something like really good. No, I... I'm going to had something like really good. No, I coined another phrase real quick. I could say anything. No, the mic is yours. I know.

I think we, we covered things pretty well and I really appreciate it. Cool. Good to have you. Thank you so much. Thanks. All right. That's it. Thanks. All right. That's it.

The show's done. Such a good conversation with Sarah. If you haven't checked her book out yet, go and get it. It's awesome. Links are in the show notes. And coming up next week on this show, we are at Vancouver on the Expo Hall floor of Open Source Summit North America 2023, bringing it to you here on the pod. Thanks again to our friends at Fastly, Fly, and TypeSense, and also to our good friend

Break My Cylinder. Those beats, they're banging. And to you, thank you for listening. Appreciate you tuning in this week. But that's it. This show's done. We'll see you next week. But that's it. This show's done. We'll see you next week. Thank you. Game on.