StaffEng Podcast

Will Larson (Calm)

Please note that this episode contains brief mention of suicide.

Today’s guest needs no introduction! Of course, but they will get one anyway:

Will Larson is the CTO of Calm and has worked at Stripe, Uber, and Digg. He is also an author and has written two books, one of which is on Staff Engineering and serves as the inspiration for this podcast! In our conversation with Will, we discuss one of his earliest blog posts on a catastrophic launch at Digg and why he felt it was important to write about his experiences. We talk with Will about the expanding role of Staff Engineers and how that is affected by the rate of change in the field of startups and technology companies as a whole. Later, we explore the tracks of technical leadership and management within technology companies and the pros and cons of the pendulum model. Will shares what he’s learned about the skills needed for leadership positions and why working with a team of managers versus a team of engineers requires a completely different skillset. After that, we talk about Will’s career in writing and public speaking. We loved having Will on the show, so join us for engaging conversation spanning many topics from the potential for leadership in technology companies to the joy of writing!

Links

Listen

Download Episode

Transcript

Note: This transcript was generated using automated transcription and may contain errors.

David: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We’re interested in the areas of work that set staff plus level engineers apart from other individual contributors. Things like setting technical direction, mentorship and sponsorship, providing engineering perspective to the org, etc. My name is David Noel Romos and I’m joined by my co host, Alex Kessinger. We’re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today’s guest.

Alex: Yeah, today’s guest is Will Larson. Will is currently CTO at Calm and previously worked at Stripe, Uber and Digg. Most important for this podcast, he’s also an author. He’s written two books, including a book on staff engineering, which was the inspiration for this podcast. Our conversation takes us many places. I think it’s best to get into it and let you all hear it for yourselves. Before we get into the interview though, folks should know that our conversation briefly talks about suicide. Folks, please take care of yourselves. Okay, so I want to dive right into this. I want to take you back to a blog post that you wrote a while back. I think it might have actually been the first blog post that I read of yours. It’s the Dig V4, a launch born of optimism. In that post, you sort of. You talk frankly about a kind of bumpy launch in your role in it. I’m sort of curious what led you to write that blog post.

Will: So this is definitely a blog post I really enjoyed and I might have written this like three or four years ago at this point, I don’t quite recall, but there’s just like certain moments in your career that are really, like, pivotal for you personally, even though, like, you might not have done something very impressive. But at the top of that blog post, there’s a couple of pictures from that time. And so we launched a Digby 4 and it’s just like the most amazing day. We had caterers. Literally, they got caterers, and we’re just in this giant warehouse. So it’s not like a reasonable place to have caterers. It’s like a very unreasonable place to have caterers. And they’re carrying around sushi and they’re carrying around flutes of champagne and they’re making drinks for you. But our site was down the entire time. It was just catastrophically bad day. And so all the engineers and the folks on the operations or around this table, it’s kind of war room, as they call it, at that point in the center of the room just desperately, literally. This is before aws. So we were literally reimaging servers to spin up the new site and that meant getting rid of the old site because we couldn’t have both. We didn’t have the capacity. And then everyone’s around us just drinking champagne, eating sushi. And I just think it’s really special and important to memorialize days like this that are just so weird. And at the time people looked at us like we were complete clowns. Like who are these idiots who can’t even run a site that hosts funny cat pictures? Right. But the reasons we got there from a business perspective were really hard to avoid. And I think it’s interesting where you can both the Internet’s like, these people are fools. But also seeing exactly the business pressures each step of the way, I think really hard to avoid in that room, surrounded by champagne, looking like fools on the Internet due to those business pressures.

Alex: Yeah, I think you sort of touched on. One of the reasons why I asked this question is that it sort of memorializes like a moment in a career. And I think one of the things that I saw in that article was like my own experiences of like sort of wanting something when it wasn’t ready. Like I feel like that’s actually a fairly common experience and something that propels people to learn more about their job. To say, like, I think sometimes it’s like, oof, how do I not do that again? And others. I actually think at the end of your post you sort of wrote, you said it made sense how we got here. And so I’m curious, do you feel like folks who eventually become staff or staff plus are almost required to have experiences like that in order to achieve staff or staff plus?

Will: I do think there’s this interesting kind of balance here. Or I think one of the special powers of the Staff plus folks is they’ve done it before and so they’ve made some of the mistakes along the way. Conversely, I think that one of the biggest ways I see folks at this level screw up is they start a new job and they pattern match on the old job and you’re doing it the wrong way. It has to be we can’t use Jenkins. Jenkins is trash. You can’t use GitHub. GitHub doesn’t scale or just this list of really over learning the lessons that happened before. And sometimes like things that I did a decade ago, like just don’t make sense anymore. And if you try to like convince people that, you know, for example, at Digg, we were really early users of Cassandra. Cassandra, at that time, like, the running joke was that it was like a Trojan horse released by Facebook to, like, ruin a generation of startups. It wasn’t good software at that point. Today, though, Cassandra is incredibly stable, used at an enormous scale. Really, really good piece of software. But there are still people I worked with a decade ago who use Cassandra and just won’t touch it ever.

Alex: Yeah.

Will: And so it’s really easy to overlearn these lessons. So it’s this interesting balance of, like, how do you take your experience that you’ve won in a really visceral way, but also not, like, privilege your experience so much that you can’t learn anymore.

David: Yeah.

Alex: I wonder if, like, maybe somehow, like, do you think that maybe, like, we’ve gone through this, like, generational change, right, where, like, we, a lot of us did screw up or made big, you know, and now that knowledge is starting to diffuse and. And, like, maybe that is also why staff has grown, because it’s like, there has to be keepers of the knowledge, maybe, or something like that.

Will: It’s an interesting question. When you say staff has grown, do you just mean that the number of people in the role, or do you mean, like, the scope and complexity of the role?

Alex: Well, I think both of them, like, sort of like the invention of staff, the sort of, like, diffusion of staff across the industry. And now even, like, I think, you know, we’re seeing people do staff engineering, you know, in lots of different domains. Right. So it’s like, it’s sort of growing in all sorts of dimensions.

Will: I think that’s a really good. That’s a really good observation. I think there’s a lot of forces that are driving the expansion of the role. And one of the pieces is that, you know, when I started working, there were very few systems out there that were more than, like, five years old that were in, like, the Internet space. Like, the Internet was just, like, pretty new. So even things like Yahoo search for it got to work. Like, it wasn’t really that old. Like, it just hadn’t been running for that long relative to, like, some of the systems on the Internet have been running for, like, a really long time now. And I just think the complexity of that is, like, we’re starting to find it a little bit in kind of the areas that we’re on. So one piece. I just think the industry is getting weird and complex. The rate of technical change is not slowing, though, and in a lot of ways it’s accelerating. And there’s a lot of, like, tribalism. Around technologies and that create a lot of technologies go obsolete sort of before their time because they become like uncool. And like PHP is a great example. Like when I started Yahoo, like I was doing PHP programming and like that’s just like what all the front end code was. It was like I remember like using APC to get like the Flash like file upload progress bar working. And this is the only like PHP like APC Flash widget. The only way you could do this like basically at the time and now like if you said you use like Flash and PHP like people like wouldn’t like use call you for an interview, right? And that’s an exaggeration. There’s a lot of great companies using PHP now, but there is like the tribalism that’s accelerated the rate of change. So I do think the rate of technical change kind of accelerating largely driven by like trend as opposed to like actual technical innovation. Like this is one thing that’s made it like increasingly important to have folks at the staff level who can kind of have context in a lot of cases like push back on trends. Two, like the software itself is getting older. Three, I do think the hyper scaling kind of era where we’ve had these organizations that pop up and kind of grow really, really quickly, like that business model has created more demand for staff because when a business grows at a sort of sustainable, coherent rate, the problems get fixed usually early on or they become like we will never fix the style problems where you just never try to fix it. And there’s like companies out there that have been using like MySQL or Oracle database or something for decades and they’re just, they’re never going to switch and like the data model is like really hard to work with and they just don’t change the data model anymore and they’re just kind of like never going to change it problem. And so I think with hypergrowth though, like the problems happen so fast and they’re like so extraordinarily painful. Like when I was at Uber and I pitched candidates like my actual pitch to candidates was like the great thing about hypergrowth is problems are so bad they get fixed. And I think that’s like a real up which some companies never fix problems, right? And at a hypergrowth company they always get fixed. The downside is that it’s like just really unpleasant working there a lot of the time while the problems are coming together. So I do think the business model has created a demand and sort of requirement for this level of like tenured senior, like Technical leader on the individual contributor side as well.

Alex: Cool. I didn’t know that you’d worked at Yahoo. I also worked at Yahoo around 0506. One of the things I remembered about working there is that I did do a lot of php, but that one of the things that they would do is they would sort of like hook in like, C backends to sort of like accelerate php. And I think of that as an interesting sort of like, proto platform that, like, no one really talked about it in terms of platform. They were like backend engineers. But it was sort of like a way to cross the boundaries. Anyway, I didn’t really have a question there.

Will: I will just say, like, the thing about like, Yahoo or these older companies is like, they kind of invented like every version of the Internet first, right? Like, there’s like Yinst, which was like, basically like apps, but like Yahoo. And they had like six or probably maybe by now like 12 different versions of it where they rewrote it from scratch each time. They did like, really sophisticated stuff. It’s just it was like all like, local, so you never really saw it anywhere else.

Alex: Yeah, no, that’s funny. Why? It’s. Oh, man. I was brand new. Like, Yahoo was my first professional sort of like computer. And I was just ruminating about this the other day because, like, I remember spending weeks getting my development environment set up, right? And I was just thinking about, like, I can just hand people docker containers nowadays and like, here you go. Right? And it’s. I think, though that, like, containers are standing on the shoulders of that learned knowledge. Like, so many people understand the pain. So it’s. We’re sort of like pulling that knowledge forward through sort of like technology, technological diffusion somehow.

David: I’m curious about. So, I mean, you’ve obviously sort of worn a lot of hats in your career and today you’re a CTO at Calm, and you’ve written a book about management and you’ve written a book about staff, obviously. So I’m interested in sort of how you think about the interplay between the management track and the technical leadership track.

Will: Yeah, I think that’s a really interesting question. And there’s. Man, there’s a lot of different perspectives in the industry, right? Like, I think one perspective that I heard a lot at Uber is like, you know, what a manager does and a senior engineer or what an early staff engineer does are very similar. But as you go further down the paths, they diverge more and more. Where, like, what a VP of engineering does versus what like a principal engineer does like totally different was like that perspective. And you also see places, I think like Google, where like being like a technologist remains like really central to in like the management track. And you have kind of Google VPs who move to other companies and are like trying to be staff engineers there in addition to being the VP of engineering and often really piss off everyone they work with. And so there’s lots of different kind of veins of evolution here. And it’s not that there’s one that’s right per se or one that’s wrong, it’s just recognizing there’s lots of veins of evolution I think is really important. The industry is still at a phase when people are trying lots of different things. And some of them are going well, some of them are going really badly, but most of them are working to some extent depending on the company. And so it’s hard to say which is right one or which is the wrong one. Similarly, there is an idea that managers, when they switch over, should stop programming immediately. Because if you try to be like a tech lead manager or split you like, it’s really hard to do both well. And some of the things when you try to be like a TLM make you a much worse manager because you trying to learn how to be a manager for the very first time is hard. And then if you’re also trying to be the tech lead, usually are really bad at one of those two roles. Either like you’re doing a terrible job as a tech lead and you’re kind of getting the way of someone else on your team, or the tech lead is so comfortable that you just kind of use all your time to do that and you hide from the management tasks, which are not what you want, but sort of the career path pushed you into it somehow.

David: Great.

Will: So I think every different company will find its own version of what it wants on this. And I think to me one of the most important things is just management’s a bit of a different career and the feedback cycle is slow. I think staff engineering, the feedback cycle is slow too, where you might have an idea for a big improvement. It takes two years to actually get it rolled all the way out, then another year before you know if it was actually a good idea or not. So it can take quite a long time, which I think people don’t always quite know going into it, how weird it is to get feedback at that reduced rate. But I think a lot of companies are still forcing people into management roles for career growth or compensation growth. And really stopping that, I think is My biggest hope in terms of what we can confirm or get more consistent on as an industry is just people go into management for purely compensation reasons. It’s bad for them, it’s bad for the folks they work with. How do we make sure that through staff roles and the kind of real empowerment of leadership for people in these roles, that people need to do that. If we just standardized on that, even though some of these other questions are still open, that would be amazing to me.

David: Yeah, that makes sense and I agree with you. But I’m curious, maybe kind of going back to the context of the evolution of the staff role that you know, we’ve been observing. How do you think that like have there always been staff type folks in large companies to some extent, maybe even outside of tech? I guess like one of the things that I’ve observed or that I’ve thought about is like when we think about organizations in general, growing organizations, Andy Grove talks about know how managers, right, in high output management. And it’s this idea of someone who doesn’t have direct reports, but who still sort of functions like a manager in a lot of different ways. And that to me resonates a lot with sort of some of the staff archetypes. But if we go back further, you know, like another example that I think of a lot is that, you know, some folks have drawn the analogy between sort of the way corporations are structured and the way military organizations are structured. And in that analogy, I think of staff engineers as sort of like the non commissioned officers, right? The people who are sort of building a bridge between the boots on the ground, so to speak, and like the, the management core. I’m curious, that resonates with you and if there’s sort of other analogies that you think make sense or like sort of in the history of organizational evolution, like how the staff role sort of fits into it.

Will: I spent some time while I was writing the book trying to answer like, where did this title even come from? So like, why do we use this title? I did not get to the point where I think there’s a canonical answer. My sense though is that this largely came out of like research things like, you know, park, you know, like these different like labs like that had like a staff level kind of title, member of technical staff or something like that. And in most of those labs the kind of idea of leadership and technically like people and technical leadership was just like one track. And they really did not try to distinguish between these two. And if you go into academia, academia is also like largely the same where there’s no idea of like the professor manager or something who’s like managing all these professors and researchers. Like that person is the leader on the kind of the research side and oftentimes a terrible people manager, but a brilliant scientist or something. And there’s lots of stories to this effect of labs where people did great work but did not enjoy working with the principal involved. And if you look at the product side, the product side mostly doesn’t have this distinction for product managers. A few companies do have staff product manager roles or something now. But for the most part the people management and the proficiency are the one. If you look at like the legal like generally to be a leader on the legal side you must go into people management while also remaining like quite involved in like the legal kind of like technical work to be a cfo. Like you don’t get to be a CFO by being a great people manager. Like you have to do like all the professional finance y, like the accounting, the FP and A and like you have to build those skills to end like somehow be a people manager. And so I do think it’s kind of like a rare privilege for us in technology to actually like split these two apart. And the interesting question is like why, why have we gotten the privilege? But also the seemingly like need to do this? And I think it’s the rate of change is extremely high. These companies that are changing very very quickly and the industry is just like very, very, very new. And potentially you could argue that actually like most companies are becoming technology companies. Although like you really have to ask yourself what does that even mean? And I think there’s a lot of different ways to think about what it means to be a technology company or not. Like that’s like a whole different discussion. I think Andrew Chen has a really good blog post about kind of what is a technology company. But the key centers entirely on the business model, not on web software involvement. Whereas we talk to technical or software folks, they typically are going to say like oh, what makes technology company is being engineering led and not talk about the business model at all. So there’s lots of ways to think about it. But yeah, it is interesting to me and I do think it’s just the, it’s an early industry and we don’t really understand what we’re doing by and large. The interesting thing is going to be I think one of two things will happen. If you are a believer in like the economic efficiency, then you would believe that the size engineering organizations will shrink over time as like platforms and tooling will rise up to kind of like capture more and more of the repetitive work. That’s like one worldview. I think the other worldview is that like most companies become technology companies in terms of being like primarily enduring headcount. And these roles will remain largely differentiated simply because of the volume of work to be absorbed. Personally, I think the latter feels a little bit more authentic to me about what’s going to happen. But I think it’s important to have both possibilities in your mind as you think about 30 years out. A lot could happen in 30 years.

David: Yeah, I think that’s interesting. The analogies to legal departments or finance departments is actually something I hadn’t considered and it’s fascinating. It kind of points to like staff plus roles in engineering being sort of like an anomaly and actually like it’s much more normal to have technical leadership and management living on the same track. Or maybe normal is the wrong word but more common. I’m curious then what you think about like Charity Majors has this awesome blog post about the pendulum between technical leadership and management. And I know that that’s something that you’ve explored yourself switching back and forth. I’m curious sort of how you think about that. One of the things that I’ve been curious about is like to what extent or at what point does it not work to switch? Like if you’re like if you’ve been on the technical leadership track the whole time, it seems unlikely to me that you magically become like a director or something. So I’m curious how you think about the interplay between the two paths.

Will: A lot of thoughts here. First, I think one of the realities is like getting a director title or director role. It’s like sort of like interviewing well and like someone wanting to give you the role in the title. So you know, it’s totally possible to get that role without ever having managed before, for example. And so I think people want to view interviewing and hiring as like this rational system of like kind of free like economic system where there’s like supply and demand and then like these curves that bend. But it’s like there’s a lot of people involved and there’s like a lot of just like weird stuff that happens and like you might have like a really special skill that is really highly valued and they will give you a title and a role that doesn’t quite make sense from like a purely economic perspective. Right. So these are not perfect optimized systems. These are lots of one off oxygens that weird things happen. Two, I do think the pendulum model is really interesting. I think it’s an amazing blog post and I think it’s right in a lot of ways. But I think it kind of depends what are you trying to do here. I do think from an economic perspective, switching a little bit early on is really powerful. Where I think a staff engineer who’s done some management just knows how to work a different way. It can also be really clarifying if you like, hate the job. Like, I know people who are like, I think I would like management more, but I haven’t tried it. I think if you try it, you will know probably in a couple of weeks if you like it or if you really hate it. And then just like being able to close off that avenue of exploration is really powerful. And it can go the other way where you like switch over and you love it and you’re like, I never want to kind of give the staff one and I’m going to close off that avenue of exploration. But focus is really powerful. I think economically though, it’s really hard if you go decently far on the management track to switch back without a really significant financial penalty to doing it. There are of course counterexamples to doing this always. You can always find counterexamples to anything. But particularly if you think about being a VP of engineering, if you’re a VP of engineering at a, a startup, like, you’re going to get offered like 1% equity, like approximately as a staff engineer, you might get a fourth of that, you might get a tenth of that. And it’s just, there’s really no way to overcome that. Like you will find as a staff engineer, there are startups that will give you 1%. But if you were the VP of engineering getting hired there, you would get like 4% then instead or something like that.

David: Right?

Will: So you can, you can kind of make the counter argument. But like, by and large, I think it’s actually really, really hard to make it effectively. There’s entire recruiting firms out there for hiring VPA roles. That industry doesn’t exist for staff plus roles. So I do think there’s a real economic penalty here. I think it’s interesting to ask why that is. Most VPs and CTOs aren’t that good. I think you work with them, you’re, yeah, this person’s not that good, but they’re getting paid more and they’re in a really esteemed position. And then some staff engineers are bad, but the ones that are bad are usually bad in terms of their behavioral purposes and generally from A technical perspective. The staff plus engineers I’ve worked with have been pretty solid. I think in both cases, man, if we just knew how to evaluate people, we would make much better decisions. But evaluating is just incredibly challenging.

David: Yeah, that’s really interesting. I think it makes sense to me that the path back from management to staff plus would be difficult both from a compensation standpoint, as you outlined, and also I think my perspective, I’ve worked in people management a little bit, but it’s been a while. My perspective on people managers broadly is that the sort of technical proficiency tends to degrade after a while if there isn’t really intentional effort to keep it up. And so I think that’s a challenge as well for sort of the move from management toward technical leadership. But what about the other direction? Like you mentioned earlier, this idea of like, you know, a distinguished engineer from Google goes and is the CTO of a hundred person startup or something like that. I’m curious, like it seems to me that the people management skills aren’t something that you can just sort of similar to not being able to pick up the technical proficiency at the drop of a hat. The people management skills also can be picked up at the drop of a hat. And so I’m curious, sort of how you’ve observed that model working or like what sort of advice you would have for staff engineers who like are really interested in the technical track but are also interested in eventually sort of organizational leadership.

Will: I think it’s an interesting question. I think when you think about what like a people manager needs, there’s like three or four buckets, some of which you can do like really, really well among the staff plus kind of career. So problem solving without authority, like I think this is like really core to like kind of staff plus engineering, but also like as a VP or CTO or whatever. Like you do a lot of problem solving without authority as well. And I think the perception of like authority, like in both cases, like people will probably think you’re empowered in a way that you’re prob. Not, but people think you are. And a lot of that power is just like the fact that other people involved like trust you and are willing to kind of listen to you in like a serious way. So I think that’s something you can develop, can get really good at and caring about people is something you can like develop and get good at or. And you can argue a little bit about whether that’s innate. And I think there’s parts of that that are innate, but I think there’s caring about people from like a. Oh, here I really want to care about people like versus like the impact of actually doing things make people better or support people. And I think you can really get a lot better about the impact portion of caring for people. Where I think it’s easy, you kind of start where you are in terms of like how much you care. But a lot of people care about helping other people, but mostly get reframed as like non collaborative or not actually doing work to help and kind of increasingly get tuned out. And so there is like a skill set of like figuring out how do I channel my energy of caring for other people into like things that actually help them as opposed to channeling them into like getting fired, which took me a while to like understand how to like differentiate those two a little bit. There’s like a third bucket which is just like the process of like running an organization. And it’s really hard to pick up the experience of that because there’s I guess like two different big buckets there. There’s like the day to day and there’s like the really weird exceptions. And so the day to day there’s like running performance reviews, running calibrations, doing compensation, doing one on ones, doing career growth. Like and you can, you can you just get better as you do these up to a certain point, at which point you like often get worse because you stop paying attention to them. But you can, I think it’s hard to build like a lot of those without, without seeing them. And that’s where like switching from like managing a team to managing a team of managers is, is really hard. It’s just like a totally different set of skills and it’s a different career and no one really tells you that. And you just suck at it for a little while while you figure it out. And so this is where I think it’s hard to kind of cut over laterally because you just are missing a lot of those skills. The other piece though is the exceptions. And there’s just. As you’ve managed long enough, you just see some really weird stuff. And so yeah, I could kind of go on on this topic, but you know, like at Uber, like I had a friend come interview, we, we rejected him and he committed suicide that week. And that was incredibly difficult to experience. Right. And as you’ve managed long enough, you just see like a lot of really weird stuff that is difficult and you process it and try to learn from it or not decide not to learn from it, as is the case in a lot of these situations.

David: Right.

Will: And you come out having seen it before. But it’s just really hard to develop that without just having gone through all these incredibly odd exceptions that pop up that you just won’t see as a non managerial role.

Alex: I’m sorry to hear that. But I also appreciate you telling it because life is messy and I think that like you said, as we progress in our career, there’s just things that we’re going to see that are hard to think about but we still keep moving forward and hopefully we can learn if at all possible.

Will: Yeah, I think that’s really important and something that I believe and try to center on is that we can fear can prevent good things from happening, but fear can’t prevent bad things from happening. And so if we spend a lot of time anxious and worried about bad things happening, they’ll still just happen anyway when that happens. I could have never imagined something like that happening. It just would have never thought it was possible. It was just so out of the left field. But there’s lots of good thing is that like by worrying about things, bad things happening, I could like not, not have that happen. So I just try to remain centered on like not stopping the good things from happening in a way where I can’t stop the bad things from happening anyway. Because otherwise like, you know, it’s a real life like we’re living and like we have families, we have friends and they’re going through different things and you just can’t stop things from happening. I try to keep that front and center. It’s. There’s just a lot of chaos and work and even in really well managed organizations, the businesses change. You just can’t stop change. It’s really hard to be in a leadership role on management, staff plus engineering, anything if change makes you uncomfortable. Because change just never stops.

Alex: Yeah. On that notion. I know that you’ve written a lot about systems and even in this interview we’ve talked a lot about the rate of change in technology. And so I wonder, the level of complexity is just growing and complexity can be bewildering, but it’s also like how you actually overcome new challenges. Like you have to complexify in order to do new things. And I’m wondering like if you as a leader have to empower people to deal with complexity, would you rather have a person who can command or would you rather have a person who has to lead by influence? And so like you said, I think that staff engineers often have to lead by influence and managers can sometimes lead through sort of like command. Please do this you know, in the face of complexity, do you think that might explain the sort of like ascending role of these folks who really have to lead by influence?

Will: I think that’s a really good question. There’s so many different types of change and complexity. Right? I do agree with your point. I think complexity is. Every successful business has more complexity and if you don’t have more complexity, your business is probably not growing. And so I do think this is like a sort of the table stakes of success is like dealing with complexity. You know, accountability is I think ties into this a lot. So I think there’s companies where if everyone is like individually accountable for their work and are actually accountable and there’s like a huge delta between what companies say people are accountable for and what they’re held accountable for. Right. And there’s lots of companies like we hold everyone accountable, but then like the in practice like it’s do we like you or not? And then we hold you accountable if we don’t like you or something like that. That happens a lot. If you actually hold people accountable, typically through creating a culture where people hold themselves accountable, then I think you don’t need that much top down, mandate driven work until you hit some level of complexity where you just can’t coordinate all the pieces individually anymore. So I think there is like a point where just like the amount of change coming that you can’t control, it’s really hard to isolate at which point I think companies start reverting back to top down direction because it’s just too slow. And there’s a great article recently between Biden and Xi talking about autocracies versus democracy and the rate of response in these two different forms or styles of government and whether the 21st century is just such a fast moving century that democracy is too slow. And I think it kind of is a parallel to the question you’re asking where I do think in some cases any decision made quickly is going to outperform the right decision made slowly. And I think conversely there’s also a bit of expression of what we believe and what we value and how we want to solve problems where we might be willing to take some pain to get through more of a consensus style because we fundamentally believe and the people who will join us and work with us on that journey believe this is the right way to do it, even if it doesn’t work as well in some circumstances. So I do think that there’s a really important values and piece to center there where I do think if you focus only on the efficiency of solving certain problems, you end up in a really weird structure. But long term, the thing about change is change changes and we don’t keep having the same types of change. And so I think when we talk about a little bit more of like a collective, like group and less like top down authority, the thing this really helps us is like long term stability as change continues to vary and evolve over time. I don’t think it’s particularly effective or efficient in terms of like responding to the same types of changes happening a.

David: Lot in that context. I’m curious. So one of the things that I think is reasonably well defined, maybe there’s variations, but I think it’s reasonably well defined the delineation between sort of staff engineers and management when it comes to sort of how technical decisions should be made. I’m curious if or to what extent you think staff engineers should have influence in sort of team growth, team dynamics, team culture, things like that.

Will: Yeah, I think that’s a great question. I think there’s an interesting idea. So a lot of companies will have a product manager and eng manager kind of joined at the hip and kind of have joint accountability, but do different work. And I do think about the staff plus role and the engine manager role in a similar way where there’s just a lot of work to do. And I think some staff engineers are like, I should be in all the calibrations, I should be doing like the performance reviews. And the problem is there’s just like too much work where if you actually double up on everything, it just won’t get it done. And so I do think there’s a piece of relying less on everyone does everything and more on how do we make sure we’re aligned and believe the same things and do it that way. Because I think otherwise you just don’t get much value from having two people doing the work. It’s actually less efficient to have two people doing it because I can, you know, make decisions quickly if I have to coordinate with you on like each of the decisions. Like we’re pretty slow. So in general, like I think the effectiveness is what really matters and I think having two people overlapping a lot usually is not the right way. That being said, I do really believe in this idea of like each pairing and sometimes there’s like it’s a trio or it’s like a pm. There’s an engine manager, there’s a staff engineer kind of working closely together, maybe like a product designer or something as like a fourth piece, figuring out the balance for themselves. It doesn’t have to be this exact set of responsibilities. But in general, I think if people are really focused on why am I not allowed to do something? It’s actually a relationship and a trust issue as opposed to because I’ve never had a staff engineer I’ve worked with where if I’m like, oh, let’s just do all of this managerial stuff together, a week later they’re like, actually, I would love to not be doing this. And so usually by just like letting them do it, they will realize they don’t want to do it pretty quickly.

Alex: Interesting. So changing gears a little bit, I think a lot of people who might have like read your books or followed your blog might remark on just sort of like how much stuff it seems that you do from the outside looking in. And you know, I was curious, given that you write books and blog posts and you do community organizing, all sorts of stuff, you know, how do you decide how to spend your time? Like, how do you strike this balance between all the things that you want to do in your life?

Will: It’s a good question. And I’ve been thinking about this a lot. So I think first, I think if you look at my writing, if you like actually looked at like my writing over the years, like there’s a period From I think 2013 to like 2016 when I wrote like effectively nothing, maybe wrote like four pieces over that like three or four year period. I just like, the work situation was really, really challenging. Some other stuff was going on and I just like didn’t get anything done in terms of my personal hobbies on this side. Like, I didn’t speak, I didn’t write, I just ran out of energy and I just did nothing for three years. Conversely, like the last like four or five years have been like really prolific for me. There’s just been like a lot of stuff that has been possible that just wasn’t possible before. And I’ve been really excited about it. So I did a lot more speaking two years ago, ramped that down a little bit as I think. Public speaking on average, I think just isn’t like my personal medium that I want to spend a lot of time on. I really enjoy the privilege to get to do some of the speaking. But I look at my writing and I look at my speaking and I’m like, if my writing’s better, I can do it faster. I just think I should focus on it a little bit more. Some of the community building and I think the communities that I’ve built, kind of like two different ones that I’ve worked with. There’s this techwriters.dev, and I think that Community is like sort of trailing off a little bit. I think it suffered a bit for me finishing my book in the sense that the book was really centering for me in terms of that. And there were three or four other folks at the same time working on books. And I think the four of us kind of have all finished our book and it’s lost a little bit of the gravity kind of from that. But also I guess I think it’s interesting to share here, but actually five weeks ago I had a stroke because I was in the hospital for, you know, three days and you know, wasn’t able like lost the ability to speak for like six to seven hours.

Alex: Wow.

Will: And coming back from that, it was just like utterly mind blowing experience. First, don’t recommend it if you can avoid it. Second, like really humbling. Right. Like the first two weeks that I was back wasn’t working. My energy level was just incredibly low and I just like sat on. I couldn’t use a computer the first week because they were just like too many windows open. And I just like, it’s just like overloading. I could only use a phone because phones really zoom in to one thing at a time. Yeah. And it took me, it’s only a month later kind of that my energy level is really back to approximately where it was. But even now at the end of the day, I’m still just like, I just have no energy left to write. And so I think it’s been humbling in a lot of ways. Right. Where I think it helped me articulate, which is like, I like to be kind of right at the cusp of too busy. And then I think with that all of a sudden where that line was like completely shifted and it’s been like humbling where I just really haven’t written anything since that. And I think at some point I’ll go back into it, but with like a young kid, you know, working pandemic, you know, like trying to like be present in my relationship with my wife, I just like kind of like lost the energy to write. Right. So I think there’s like a bit of like a seasons of your life bit to it where you have to know like what you’re trying to do and like put the energy where you think you can. And I think sometimes you just can’t and you just like, I just don’t have it right now. And so I think, you know, I hope to get back into Writing a little bit more as the energy level returns. But just like, I think you also have to like, recognize your life as like, kind of a dynamic thing. And like, you’ll have like, periods when you’re just. You’re just not readying. And it’s not like, oh, I’m. I’m not writing because I’m like, public speaking. It’s like, I’m like, not doing anything in public. And like, that’s okay. And so I think just being, giving yourself some grace is important. And the last thing I’ll say is just that there are people who are trying to make their profession like their. Their career, like, their livelihoods through, like, writing, through speaking, et cetera. And like, for me, like, I’ve. I’ve always really focused on not doing that. You know, I. I want to, you know, make my living. Like, my profession is like, really like, like the work that I do professionally. You know, working at calm right now really, like, making sure I have the energy to do that. And then if I have more energy to like, you know, to write, to speak, et cetera, like, that’s. It’s always number two for me. And just like, really knowing where it is, I think has been helpful, I think. My sister is a graphic novelist, and so, like, the way she lives is she like, sells graphic novels and people buy them. And so, like, that to me would be incredibly stressful. And I think not having that stress has always been important. It keeps it fun for me. Whereas if I was actually living off this, I think it would be really, really challenging. Wow.

Alex: Well, I’m glad that you’re here to do this interview, and I’m honored that we get a bit of your time given all that’s happened recently. So thank you.

David: I mean, first of all, seconding what Alex said, it’s really fun to have you here. We have two questions to wrap up with that we tend to ask every guest. First of all, the question is, when you think about resources around sort of staff plus level engineering, books, blogs, etc. Sort of what has been the most influential to you? And I want to start by saying that the resources that have been most valuable to me have been largely your contributions. And so I’ll take this opportunity to say thank you for that. But I am curious to hear your answer as to sort of what has influenced you the most in that vein.

Will: Well, first, thank you. I appreciate that. And I think the thing about the resources I’ve put together is that a lot of what I’ve done is I’ve synthesized Like, the different things, the experiences of folks like Alex, the experiences of folks like Michelle. So it’s been more trying to synthesize, like, what’s real and pull it together. And similarly, there’s a ton of amazing resources in my. You know, the book, like, has, like, a bunch of links to the resources. Also, like, on staffenge.com, there’s like, a link to the bunch of the resources that I found really helpful. But there’s a tremendous number of people out there. I think Tanya Riley has done a great job of evangelizing what real Staff plus Engineering is, and I’ve loved a lot of the stuff that she’s written, particularly the glue work piece, I think was really phenomenal. But there’s just a tremendous number of pieces out there, so I won’t list them all. But I really think I believe in the value of talking to practitioners because they give you what we write and what we live. Like, when we write online, there’s, like, all these, like, caveats, like, how do we tell, like, the most optimistic version of this story? So it looks like I don’t have a bad attitude, like, how do I remove the villain from the story so it looks like I don’t just blame other people for everything? And there’s, like, all these pieces, and you get, like, a version of the story that’s, like, really different, where if you just talk in a group, like a learning circle or something, you get, like, a much realer, like, not filtered version that I find really powerful. So I just think talking to folks in the industry in these roles is really, really valuable in a way that, like, things written publicly, like, just can’t because of your obligations to reshape it into something that presents kind of the best version of yourself that you want to be interesting.

Alex: I actually, now that you put it in those words, I hadn’t thought about this before, but it’s almost like your book is an ethnography of staff engineering. You know, I don’t know if you have any training in that, but it definitely, now that I think about it that way, it reads like that you’re pulling the experiences of folks into sort of, like a cohesive narrative.

Will: One of the complaints about my first book, An Elegant Puzzle, was basically like, this is just some idiot who worked in Silicon Valley talking about their experiences, which I think is a totally valid criticism of the work. Right. And so I wanted to not step into that same kind of approach and kind of center it instead on what are real practitioners saying, as opposed to, like, projecting Too literally, like what I thought they should be saying. Conversely, like, there’s not like a ton of consistency. So there, there, there, there certainly is like a lot of my perspective, like, shoved in as well. But yeah, I, I did try to approach it a bit, as you’re saying, from that perspective, because I wanted to make sure it was something real and not just like my opinion, pretending to be real.

Alex: Yeah, to me it reads like that. So the last question that we ask, we’ve been asking everyone, you know, in a typical month, maybe, you know, like, how much coding do you do?

Will: Yeah, this is a funny question. So if I go back, even starting to answer this, you, like, will kind of get the sense that if I go back five years, I was doing probably like 30 to 40% of time programming at Uber. And there’s kind of like seasons to that as well. Like, when I first started Uber, like, I was working with a team of, you know, three or four people, and we were like, we were in trouble from like a workload perspective and I was working really hard. And so I was like, directly involved in like, migrating from peak hosting, which I have a lot of kind of feelings about, into like our own data center, and so super involved there. And then, you know, we, we just only hired, like, I spent like basically a year growing the team from 5 to 70 through external hiring. And like, all I did was interview. I just, just didn’t do anything else basically. And then things slowed and I was like, started writing some, some software again. Not, not good software, but software, I think at Calm. I, like, I, I’ve done work coding like the Eng.com.com website, but honestly, like, none of my code is really doing anything important. And I think if it was like that, that would be bad, but finding ways, like, the question I think is this interesting, is like, how do you, as like a senior manager, track leader, actually stay in touch with what people are doing? And so for me, the DevOps side of things has been really helpful in terms of really paying attention to the datadog when there’s incidents, working through the dashboards to understand and diagnose what’s happening there, understanding the events, the logs, et cetera. So that’s been a really useful way to find a narrow spike they can use to explore the entire system. Even though it would be, I think a really bad day for everyone if I was committing iOS code or something like that just wouldn’t work. Well, I do miss it though, of course. Right. And I do think, you know, there’s this. The dream is like, how do I find, like 10 to 20% of my time that I could be, like, doing, like, development work like, every single day or week? I, like, look at what I should be doing and I just. It’s just irrational to prioritize it in. And so, you know, I still have the dream of, like, going back to, like, the technical track at some point. So my biggest advice to people when they think about managing make sure you finished what you want to accomplish on the technical track. Because it’s really hard to go back without disrupting what you’re starting to build. And I sort of feel the same way on the management track. It’s like, I want to make sure that I finish what I want to accomplish on the management track before I go back. Because it will probably take me like two to three years to be technically competent senior software engineer, let alone a technically competent staff plus engineer. I think it would take me that long just to ramp back into it. And I can’t. You can’t pendulum when it takes you like three years, like, be a competent senior engineer again, Right? Like that. That’s a really expensive pendulum.

David: Yep, yep. Fair enough. Well, Will, thank you again so much for taking the time. It’s really been a pleasure chatting with you.

Will: Likewise. Thank you for having me.

David: That’s it. Thanks so much for listening to staff Eng. If you enjoyed today’s show, please consider adding a review on itunes, Spotify, or your podcaster of choice. It helps others find the show and is a really useful signal to us that folks are finding value in this so that we keep doing it.

Alex: You can find the notes from today’s episode at our website, podcast.staffenge.com the website also has our contact info. Please don’t be shy.