The Engineering Leadership Podcast · Episode 30

Spend Time On What Matters

with Will Larson CTO @ Calm

Mar 02, 2021
Will Larson CTO @ Calm shares with us how to focus your time on what actually matters. You’ll hear about many of the common traps engineering leaders fall into and his frameworks to help you better target your time to focus on long-term, high-impact work.
Listen On
Apple PodcastSpotifyBreakerGoogle PodcastOvercastRadio Public
supported by
JellyFish
Empower your team to drive greater business impact & attend GLOW 2024!
ELC
NEWSLETTER
EVENTS, PODCASTS AND MORE
ELC
NEWSLETTER
EVENTS, PODCASTS AND MORE

SPEAKER

Will Larson - CTO at Calm

Will previously working at places like Stripe, Uber, and Digg. He's been writing on his blog, Irrational Exuberance, since 2007 with 600+ different posts covering tons of topics on engineering leadership, management and career.

He is also the author of “An Elegant Puzzle” and his NEW book “Staff Engineer: Leadership Beyond the Management Track.” Follow Will on Twitter @Lethain

"A lot of times they'll be like, 'Oh no one's working on this... I can make a huge improvement here!' But then they'll get signals from leadership that 'Actually this isn't valued...' And so I think it's really important to understand what SHOULD be valuable, and then understand what IS actually valued, and then make your own decisions based on that in terms of where you want to put your time."

- Will Larson


Check out our friends and sponsor, Jellyfish!

Jellyfish helps you align engineering work with business priorities and enables you to make better strategic decisions.

Learn more at Jellyfish.co/elc


Show Notes

  • When Will confronted the existential question “Am I actually working on what matters?” (3:56)
  • Where most people go wrong when evaluating how they spend their time (8:52)
  • How to focus on long-term impact and avoid short-term “snacks” & “preening” (10:12)
  • How to navigate a company that recognizes high visibility work over high-impact work (13:12)
  • How to mitigate & reduce status-chasing in your teams (16:09)
  • What high-visibility, low impact work looks like with engineering leaders (18:20)
  • “Chasing Ghosts” and the trap of projecting familiarity onto problems (20:59)
  • How to catch yourself “chasing ghosts” (27:31)
  • Focus on what really matters by seeking the “existential issues” & where there’s “Room AND Attention” (32:10)
  • How to identify and anticipate future existential issues with the “Iterative Elimination Tournament” (35:28)
  • Creating “Room and Attention” & identifying your unique capabilities as an eng leader (38:20)
  • Get projects unstuck and prioritized fast by “Lending Privilege” (42:11)
  • Why Will wrote his new book - “Staff Engineering: Leadership Beyond the Management Track” (45:42)
  • Takeaways (48:40)

Links & Resources

Transcript

Will, Jerry and I, when we were talking about preparing for this episode, one of the things that really stood out to us was there's really only like a small number of engineering leaders who've committed an extensive amount of thoughtful work about this world of engineering leadership. And you're somebody who has been doing this since 2007.

The first thing we wanted to say, just how much we appreciate and really admire the work that you do and the contribution that you've made to engineering leaders, because you have spent so much time thinking about this and synthesizing, and it's something that has just been a joy to research and read. So, First off we just wanna say thank you for everything that you do. It's fantastic.

Will Larson: Thank you. I think there's a little bit of altruism, but I think for me, writing is a way to, to learn as well where you'll often have like, something I'm really struggling with at work. And trying to figure out what I should actually do. Often when I'm trying to give advice. I'm like a very intuitive person so I immediately know Oh, what I would do is this, but when I'm trying to explain WHY I would do that, I can't. And then I have to like really write it down to actually give useful advice. Instead of just telling someone what I would do, which is like almost never very helpful.

When Will confronted the existential question “Am I actually working on what matters?”

Patrick Gallagher: That's awesome. So we're here to talk about how to work on what matters. And I think over the past few years, Jerry and I in different ways have experienced, challenging moments in our careers in life that had made us confront as you've described in some of the articles that you've written as the "mortal countdown." that we have an unknown yet finite amount of time left.

I think for me, really, there was a two to three week period where my company was going through massive layoffs. there was some death in my family. I was going through experiences in my family with divorce and family displacement.

All of this happened at once and it really shook me. And, these are things that I viewed as sources of stability. And it made me ask the question of like, am I actually using my time in a way that actually matters...

And in a beautiful way that also sort of catalyzed my decision to get involved with ELC and which is why we're here now having this conversation. And so thinking about that question of, you know, the finality of time and are we doing what actually matters...

I was wondering if there was a moment in your life or career that stands out to you where you had to confront that question of, "is this the best use of my time? Am I actually working on what matters?"

Will Larson: I can think of a couple of different examples and to me I think sometimes these are slightly different questions. There's this like finality of time, where you're you realize what you're doing, just isn't working. And then I think sometimes there's like other moments when you're like reaching for some sort of comforting task, which, it's just like a, almost a ritual where you're like, I'm going to go do this thing that makes me comfortable, even though, you know it's like really not the right thing to be working on. So I can think of a couple of different examples, one for each.

And so in the former I think six or seven years ago I was working at Uber. I was on a trip to Lithuania where we had an engineering office that mostly everyone in that group was reporting into my organization at that point. And we're doing this migration. We were moving out of our primary ... our home data center. We're finally moving to a new data center for the first time.

So I'm in a hotel room in Lithuania working at night, migrating services over to our new data center to hit this timeline of Halloween coming up. And then I got this call from my partner at the time that they were moving out.

And so you're in Lithuania. And you got a call from your partner of seven years that they're moving out while you're on a business trip trying to migrate this stupid data center over to another data center. And I think it's moments like that your entire "what am I doing here" like flips a little bit.

And to me that was a really grounding moment where I just really thought about what I was doing and what I was giving to work and like what I was giving to the rest of my life. And had to do a little bit of a reset to think about where my time was going or where I wanted it to go. And so that's like when kind of the finality of time was very like present in that moment. Right.

A different example though, where I caught myself snacking, which is one of the categories I think about where you do something comforting because you know, a lot of times, like when I eat, it's not because I'm hungry. I'm just like looking for some sort of happy moment, particularly in like the year of the pandemic, like just like I'm going to, I'm going to eat a snack. I don't need it, but my kitchen's here cuz I'm working from home and I'm just gonna eat something.

And I can think of like, when I started like an engineering book club when I was at Stripe, where I was just like a little bit underwater. And I had a couple of the things I was working on were longer and like really important projects, but projects that take, six or 12 months to see a lot of momentum on. And I was like, you know what, I'm just going to start a book club and we're going to meet and it's going to feel like I've accomplished something.

And in that moment I knew I shouldn't do it. But I just like, wanted to feel like I had done like a finished something and I did it anyway. And then, you know, like two weeks later I was like, really regretting. I was like, I should not have wasted my time on this. This is the wrong thing to be doing. And I knew it, but I just couldn't stop myself from trying to get that taste of completion from some, sort of familiar task.

Patrick Gallagher: And what's so interesting is like, it seems productive, but not. Like it sounds like bringing together people and talking about engineering leadership personally, between Jerry and I like that sounds like our dream and would be the most productive use of time anyway. And so that seems like almost contradictory.

Will Larson: There's like the book "Flow" and it talks about like, we have a finite amount of attention in our lives and we have to figure out where to put it.

On a smaller scale. Like when you're doing work at your job or whatnot, like you only have so much energy. even when there's things that are like nominally quite valuable, and I agree like, leadership training sharing your thoughts and learning from a book together, like personal development, these are all really valuable things. But if there's something really important that you're struggling on if you take that energy away and put it into something else. Even though that thing is still valuable, you're still a jeopardizing, the thing that really matters. that's where I think you have to draw the distinction

Although in a different case to your point, like that could be the most valuable thing you could be doing, but knowing your own energy levels and where you need to be focused. I think you can identify where you're cheating a little bit in that way.

Where most people go wrong when evaluating how they spend their time

Patrick Gallagher: You bring up the concept of flow and it sounds like you have a pretty thoughtful approach into assessing how you spend your time and where it fits in relation to one another. And so I was wondering if you could help us understand where most people go wrong or get tripped up when they're evaluating how they spend their time as a senior leader or as an engineering leader.

Where do most people go wrong with this?

Will Larson: Yeah, I think this is funny. I think this is a question that everyone knows the correct answer to, but actually doing it is super hard. So the correct answer is like one, like you should actually be intentional about looking where your time goes. It's like, look at your calendar, like actually do some of the calendar reviews and understand where you're spending your time.

And then two like, don't focus on like urgent short-term things to the exclusion of more important, longer things that aren't on fire.

Everyone knows that, right? By the time that you're like five years into career like, you know, the answer, but for some reason it's actually extremely hard to live that advice even when you know, it's true.

Patrick Gallagher: For that specific problem, because I, I find this, like, happens to me all the time there are some urgent messages that pop up or, the never-ending chasm of email. And there just is that dopamine drip of, "Oh, if I just fire up this one email, I'm gonna feel really good."

Do you have any insight on what's helped you focus on those most important things and divert attention away from some of the short-term snacks?

How focus on long-term impact and avoid short-term "snacks" and "preening"

Will Larson: I think there's two, two things that I think are important here. The first is that I think there's this idea that like busy-ness is a choice. and I think that's true but it's also like usually the person telling you that is an executive, who has a lot of agency over how their time is spent. A lot of folks don't have that same level of agency. So it can feel like pretty infuriating when someone's like, your busy-ness is actually a choice.

And it is a choice, but it's often not your choice. It's a choice someone else has made for you. And so the difference is when an executive says, "oh busy-ness as a choice." What they mean is "I made that choice for myself."

And when they tell YOU that busy-ness is a choice, what they mean is they made that decision for you. And so I think it can be like a little bit disorienting when people say that. But if people are really busy in an organization, it's because someone or some group of forces in that organization have like, decided that busy-ness is an important thing. And so like people aren't busy by accident. Every system, like is perfectly designed to perpetuate its current behavior. Right?

When you notice you're really busy , there is some choice that's happening that is causing that it's not yours, but it's somewhere in the organization and you can choose to actually make the investments to not have that be true.

An example that a lot of like middle managers and large companies get is kind of administrative support. And so a lot of companies make it effectively impossible to get administrative support because they want to avoid the proliferation of admins, which you know, is a reasonable goal. Right?

But then it means that you have middle managers who are like, nominally some of your talented folks who become bureaucrats. And there is a choice that has made them bureaucrats instead of empowered leaders. It's just not their choice.

And so I think that's one idea that I think is important is go talk to the person who's making the choice that is making you busy. And I think learning from that, because there is a choice deliberately happening that has put you in that spot.

And two, I think the other thing that happens, which is similar, but more subtle, which is, I think responding to the social cues. Or like, if you have a production incident, there's like something is on fire. Very few companies can reward the person who doesn't go help. And a lot of times, like you only need three people in there helping. But there is like a social pressure to go be visible.

And call this preening where you do something that's like highly visible, but with actually low value. And I think incidents are probably the most frequent example of this in engineering organization. Where engineers will jump in and throw ideas into an incident, which there's already the right people participating in it. And it's because they really want to be seen .

And they do it because it's rewarded, right? Like they get called out, "so glad that you jumped in..." "...love that this person jumps in!"

And usually the people doing the recognition, aren't in the spot to evaluate who is particularly helpful, in a given incident or not. And honestly it's like quite hard to tell who's helpful in a given incident in that moment. So I really think that these are circumstances that we create with the culture but then also some of the organizational decisions we make, like busy-ness is not mandatory.

How to navigate a company that recognizes high visibility work over high-impact work

Patrick Gallagher: So like if you're someone who's in a company that is prioritizing and recognizing people for their high visibility work, but not the people doing the high impact work. How does somebody navigate that experience in a way to be successful?

Will Larson: First, this is, pretty challenging, right? I mentioned incidents. Another good example is things like architecture review groups where people will really want to be part of this architecture team, but once they're present, they actually don't engage with it. And like their goal was to be listed in this group. And it's kind of a status orientation and not to actually give useful architectural advice.

It happens a lot. And one of the things I think that we do kind of organizationally that incentivizes this sort of status seeking is the lack of titles or the lack of clarity around titles.

And so one of my goals with this project I've been working on talking to folks who are in staff and principal engineer roles is kind of exploring like the impact and value of titles. And one of the things that happens when we don't have titles, when every engineer is just labeled the software engineer or something, is that people start assigning value and kind of status onto like random things.

And so this is negative and tons of ways, but one of it is that you'll think about, "Oh, being in this team meeting or being in that group meeting..." or whatever is the actual source of status.

So first There's a lot we can do as leaders. And I think that's not just managers, but it's anyone in a leadership role, including engineers who can push to change some of these decisions that incentivize status seeking in ways that aren't helpful.

But two, I think if you're in a company that really does value the sort of high visibility work, it's extremely hard to change that from the inside because companies reward people who understand the game the given company is playing. And so the people who are in, high status roles are people who are good in that company finding what the company values, which in this case is like work that's actually not particularly valuable. And optimizing for it.

And so I think it's extremely hard to change this sort of cultural, like evaluation of, impact. And I think if you could get like new senior leadership that, that can change. But I do think there's a bit of a upper out aspect at companies like this, where people either choose to kind of learn the lesson the company is telling them around, like do more preening or that like offends their kind of their ethos and they, leave.

So I do think it's quite hard unless you're in like a very senior role to actually change something like this. Cause it really represents someone senior's values within the company. And you can't just change those or ignore those there's something real that are coming to make the organization work that way.

Jerry Li: The two examples you mentioned about preening: architecture review, incident. I can totally resonate I've seen that a lot in my previous companies, Are there ways that can help mitigate that? Because as an engineering leader you want your best talent to focus on problem that no other people can solve.

How to mitigate and reduce status-chasing in your teams

Will Larson: That's a great question. think there's no one size fits all solution for anything. But in this case, I find if you find the scenarios that happen a lot. So let's think about incidents, for example.

Very common sItuation for a small company is that you have a Slack room. There's an incident. Someone's like, Hey, the site's down. They do an @here, everyone jumps in, everyone's trying to improve it.

And then the people who don't come help, they're like "oh where it was Will during this incident. Like I thought, Will would have been really helpful but he didn't show up. And so there's this like social pressure to just show up, right?

And then a better version of this is now you have like on-call. And then you have a rotation and, you know who's responsible to be there. but people will still feel like a social pressure to jump in. And so, how can you help people not feel that they have to jump in?

And that's where I think setting like standard ways of working. Where it's like, "Hey, the on call will always be the first person to jump in. And then it's their responsibility to ask for help if they need it. We don't need to go jump in." And by setting kind of norms and standards and structure, I think we can like, de-centivize this.

Similar for the architecture review example if you are really explicit about how you have to engage in the architecture review.

And so the easiest way to like disincentivize any behavior is to make sure, like following that behavior requires doing a lot of work.

So the number one way to push back on people who want status is to ensure that status requires a lot of work.

And so if you want to join the architecture team, that's great but like you have to review this many architectural proposals and you have to do it in this timeline. And it's this much work and we're going to review 'em together afterwards to make sure they're really helpful. And if your advice isn't helpful, we're like rewrite it until it is helpful before we send it forward.

I guess, yeah, to, to answer your question like really concisely, just make sure there's a lot of work involved in any sort of status. And as long as you do that, things tend to work out because even if you can't prevent people from chasing status, as long as you make it expensive, like they kind of balance out a little bit.

Jerry Li: How do you see preening typically reflected in engineering leaders? Because the two examples earlier, architecture review, incident is more for engineers, ICs.

What high-visibility, low-impact work looks like with engineering leaders

Will Larson: The most common example is the dive bomb we're you just jump in and you're like, there's some problem. And you're in the room trying to solve it yourself. And stead of kind of understanding like structure and the right leaders to solve it.

As leaders, sometimes we don't get a lot of feedback and it can become easy to be convinced that we have really exceptionally good ideas. Sometimes people do, which is important, but the, the lack of negative feedback is not equivalent to actually like being highly capable. And when we go into rooms, like I think a lot of rooms shut down when we, as senior leaders enter them. And then it may seem like a dysfunctional team where they seem like they have no ideas, but we've actually by our presence changed... it's kind of like the Heisenberg uncertainty principle.

You can't really tell, if a team works, if you're in it, as a leader, cause like you change it the nature of, existing. I really think, dive bombing is like number one.

I think not creating clarity around where decisions need to be made and not delegating them down is another good example. For example, every person we hire has to be interviewed by only me, before they can get approved. Like I'm the only person who has like the correct talent radar to make approvals. That's a good example of kind of like forcing yourself in to the process.

Where often you'll see people build like really sophisticated systems of managing up to get your approval. Where you're no longer really approving the candidate, per se. the team that you've asked to do this has built an entire system of how to convince you to get to yes. And they're doing even more work to convince YOU that they are evaluating the candidate. Basically every company I think that scales to some point ends up with a system along those lines.

I've seen some companies where like every piece of copy. Like every piece of writing has to be approved by you know, a very senior individual and they become like the bottleneck.

I think in senior leaders basically what it boils down to is the lack of trust and delegation is sort of the, the form of preening for senior leaders.

Patrick Gallagher: I feel like I've had so many moments of my life flash before my eyes, as you were describing some of those things

You've mentioned a couple of examples and stories of snacking. We talked a little bit about preening. I know that another thing that you've talked about is chasing ghosts.

And I think this one was surprising to me because when I learn something, I want to be able to apply those lessons to the next instance of a problem. But with this, you talk about how that can lead to some hidden problems when it comes to actually working on things that matter.

So I was wondering if you could share a little bit more about what is chasing ghosts, where have you seen that and how does that go wrong for people?

"Chasing Ghosts" and the trap of projecting familiarity onto problems

Will Larson: So every solution is appropriate to a specific context, right? And so when you join a new company, what's the classic advice that people give you? It's like, wait 90 days before you do anything. And this is like not very good advice. I think it's extremely rare as a leader to get hired into a situation where you can just like spend 90 days kind of like understanding the lay of the land.

Some things are just like really on fire and just require immediate action and some things aren't. And so there's a lot of judgment in terms of which things can wait 90 days. And it is, I think, advantageous to wait and build context when you can. But some issues are just like too serious, to wait.

And so something that I see that happens a lot for senior leaders in particular, and this happens for engineers and this happens for like managers as well, two different varieties,

But the engineer version of this is you join a company and you're like this, this just doesn't work. Our build system sucks it uses Jenkins. It uses like EC2 instances directly. And you're like we really got to roll out at Kubernetes. It's just like urgent that we do this.

And you know, like there's a lot of value to Kubernetes. There's a lot of things that are great about it. It's a super useful tool. What you would build might be much better than what exists, but there's a reason why it is kind of the way it is. And I think if you don't understand why it is the way it is and just presuppose a solution it's really hard to have confidence. Your solution is better. Instead what you've done is you've projected is something you're comfortable and familiar with onto the situation.

It's like, when you're losing a game of chess or something and you just knock the pieces over and now no one knows where the pieces are, so everyone's like equal. But you're equal in the sense that everything that was there is gone. And so that's like the individual contributor, like engineer version of it.

The manager version of it, it's like one often the same where a lot of managers come in and want to kind of reset the company architecture. This happens a lot for like product architecture, where it's like hey this is just not appropriate to the scale or the maturity, like the way we did it before at my last company was just better than this. And we just need to like shuffle everything.

And I think this is like a, an attempt to get back to something that people understand. The easiest way to be the most knowledgeable person in the room is to ensure no one knows anything and YOU know, just the slightest bit about it. Right. And so I think a lot of times, when I think about this idea of chasing ghosts, it's people trying to recreate something they're familiar with that no one else understands, which will make them the central core authority on a topic.

It's a little bit like a similar idea where the best way to be viewed as a great interviewer is to say no to everyone cause then like, you're the best because you have the highest standard. If you come in and make sure no one else knows anything about how things work you're the smartest person but ultimately I think the damage to the company is, is extremely large.

And so to me, the idea here is just making sure that you understand the context and hold yourself genuinely accountable to solving the current needs, not just erase, everything and put something you're comfortable on top of it.

Jerry Li: That reminds me of a learning there's an anthropology component to a role. When you step into a new organization often it's invisible that what happened in the past. The lack of understanding of that can lead to really big problems.

How to catch yourself "Chasing Ghosts"

Jerry Li: I think we talked about this one time when we have a peer group dinner a few years ago that for an engineering executive that when they transition for one company to another company they have a shining profile. They were hired to solve a problem they have solved in the past, but that often fails. Part of the problem is the chasing ghost phenomenon that you described that people projecting based on their past experience to seemingly alike situation.

So I'm curious two things, one, you just transitioned from Stripe to Calm with that awareness of that potential issue, what helped you to catch the things that would otherwise cause problem? And secondly, how do you see the same issue reflected in other people?

Will Larson: One of the challenges is like typically when you hire a senior leader externally onto an Established company you are being hired to solve like some sort of real or perceived problem, but you're really never getting the job because there's the belief that everything is going perfectly well. I think it does happen sometimes, but it's pretty infrequent.

So the challenge is often, like the perceived problem that you're hired for is not like quite the right problem. And yeah, that's why you're being hired particular as an executive you're being hired because you have all this context . the people who are shaping the narrative for you before you come in don't have the same level of expertise in your field likely, which is why they're hiring you to be like a senior leader, representing it.

And so I think there is, if you hold on to this like, image of what you've been told about what the problem is or what the solution is, I think it's, it's really easy to get, trapped in that. And I think you have to hold this idea of like, here's what I've been told. And that people telling me that have a ton of confidence and they're really smart people, and they really care about this company and they have a great perspective.

But then it's also like, what am I actually seeing? And like what's the delta there? Because I think, people have blind spots but also like you just have a really attuned perception to like certain types of organizational issues from your own experience that other people might not notice.

And so I think it's really important when you come in to balance these two different ideas of like, what do I actually know versus like, what have I been told and like, what can I personally build up.

You know, In a lot of cases, there's going to be like these complex relationships that between individuals at the company that in understanding those and coming to have like a firm perspective on what's happened is a big part of the initial job.

But an equally important part of the job is just like resetting some of like the previous engagements where you're like, You know, I don't really know exactly how we got to this spot, but we're like wiping this clean and we're going to start over and this is how we're going to work together.

And I do think part of the balance as a new leader is like figuring out how much do you seek to understand versus how much do you like seek to erase? I do think there is something valuable here in terms of erasing, particularly a lot of the complicated relationships, et cetera. So like hey, like we just have to start over this hasn't worked, we understand it hasn't worked on restarting over together with these kind of rules and behaviors and engagements

Two what you mentioned about kind of being that like shining on leader that comes in, this is like a really unique tool where like often there'll be someone who has been saying exactly what you come in and say, but when you say it as this like new person hired you get heard.

And I think people get really annoyed at about this and it's an annoying experience, right? Where like, Hey, we need to prioritize reliability or something. And then like, you know, you hire Jerry and Jerry is like, "reliability is really important," like "Ah Jerry is extremely smart!"

Patrick Gallagher: Supremely frustrating. Oh my gosh.

Will Larson: Yeah, it's just like so annoying. You're like, I've been saying this for years. But the thing is like a lot of people were saying a lot of things for a long time and figuring out which of these is like really important and what to exactly do about it is actually extremely challenging. Right? And so it's not just the Jerry or whoever the new leader is saying it's important. It's that you like trust their judgment to like weed through all of these different problems and articulate that as, not only one of the most important, but also like the solution as like an appropriate one.

And so I really think it's important when people have concerns like that they seek to understand why they're not happening. And often it's because the people like don't trust you and understanding that then gives you the ability to figure out how to go back and try again.

Or you're saying it in a way that doesn't resonate with them, like maybe you're talking about the engineering toil and how hard that is for your team. And they're like "objectively, I don't want your team to be overworked. But what I really care about is like these four other things over here..." you have to figure out a way to express like value that actually resonates with whoever you're talking to.

Focus on what really matters by seeking the "existential issues" & finding where there's "Room AND Attention"

Patrick Gallagher: I wanted to transition topics a lit tle bit, Will. We've covered a lot of things to help people spotlight, where they might be trapped, where things might go wrong as they're trying to evaluate if they're spending their time appropriately. But I know you've also spent a lot of time really thinking thoughtfully about how to help people figure out what to focus on, on the things that really matter.

And so I was wondering if you'd share just your thoughts about how do you intentionally focus on what really matters.

Will Larson: I've developed a little bit of a hierarchy of what to focus on. And so I can walk you through with some of the pieces and it's not like a perfect hierarchy. You don't necessarily do all of one bucket before you move on to the next. But I think it's a useful framework to just think about a given task. Cause it will fall, to any of these buckets and if not, it's probably not the right thing to be working on.

But the first one's just like existential issues and some companies have existential issues and some don't at a given point. But when I was at Digg we were like, Hey, we have five months of salary left. And if we don't get the revenues up from ads in that case, like we're doomed. And so that was like really clear it's like revenues go up more users, or like no money. And so that was like super helpful, just very clear.

And then other companies I've worked at, which I won't, I guess, go to too much detail, like almost every company, even large companies that are very established, run into things that are extremely problematic for the business if they're not addressed.

I think things like GDPR are a good example of a few years ago, a lot of companies had to get this done, or they had a lot of challenges in terms of operating in Europe. Which for a lot of large companies is just not, you can't just like pull out of Europe. Even harder than any getting GDPR working or getting a GDPR compliant solution is like pulling out of Europe somehow quickly, like that's incredibly difficult for an established company to do, right?

And so I think things like that where you just have to get it done. And you can't not get it done without harming the business immensely. So existential issues is the starting bucket.

But then I think about this idea about places where there's a room and attention, this goes back a little bit to the preening bet where oftentimes there's like opportunity and you're like, why is no one working on this?

And so a good example of this could be durable reliability improvements, not just jumping into a, an incident to try to remediate it, but actually like understanding the root causes, figuring out the stability, improvement or something to actually prevent future incidents.

And you'd be like, "why is everyone only working on reactive stuff? And no one's working on proactive stuff...?" And you're like, "here's a huge opportunity for me to show a lot of value."

And sometimes that works out. But a lot of times people at some companies who are like, "Hey, like, why are you wasting time on this theoretical work to improve something? Like we should just be shipping features and we'll deal with incidents if they happen." The reason there's a lot of room to make impact is that there's actually like a lesson, which is that there's no desire or if there's no attention on the sort of work that you're trying to do.

I think unfortunately, a lesson, a lot of folks have learned is like similarly, like diversity inclusion work is a lot of times they'll be like, "Oh no, one's working on this. I can make a huge improvement here." But then they'll get like signals from leadership that actually this isn't valued. And so I think it's really important to understand, like what should be valuable and then understand like what is actually valued and then make your own decisions based on that in terms of where you want to put your time.

How to identify and anticipate future existential issues with the "Iterative Elimination Tournament"

Patrick Gallagher: I had a couple of followup questions before you continue through your progression. I'm going to go back to existential issues. Can you share a little bit more about your framework about the iterative elimination tournament as a way to identify and roadmap some of those future existential issues to help people anticipate?

Will Larson: Yeah, this is a framework that I learned from one of my coworkers. I don't know, maybe six or seven years ago, but it was really interesting idea where basically the challenge we had at that moment is that we were a Facebook advertising company and we needed to pull down a huge amount of data from Facebook APIs.

And there were two different teams who wanted to build like their own solutions to the same problem. And one team was building this like extremely elegant beautiful, well-designed hyper scalable solution. But none of it worked at all. And it was like way behind schedule.

This other team was building this like very clumsy, like unlovable. Solution, but it like, it actually did some stuff. You could actually use it to like pull data. And so there's kind of discussion of like, how do we think about these two different approaches and like, which one do we greenlight? Do we greenlight like both of them?

And so we got this idea of this iterative elimination tournament where it's it's important to do something that's good enough to like, actually meet what you need today. Cause otherwise your project gets canceled or in like a basketball tournament or something like you get eliminated and you don't go on to the next rounds.

But also like it turns out getting to the next round isn't that valuable if you can't also win that round. And so I think balancing this idea of like doing something that's good enough to like, meet what you need today so the business stands up. But also doing stuff that's good enough. So that you're able to survive that the next round as well.

Maybe like a concrete example or another example around this is like your database is falling over. And like probably what you want to do is something like really clever, like moving to something that's like scales horizontally indefinitely, a cockroach DB, or a spanner or a dynamo DB or something.

But probably what you should do is you just take your heaviest table that's getting the most reads and writes and just move it to like a new shard. And it's like pretty ugly. It's like kind of annoying. It's a lot less elegant, but it's gonna work, almost certainly much faster than migrating everything to a new, a whole new backend.

And that then frees you up enough time to do something more sophisticated. But if you try to go directly to the more sophisticated solution. Your company's going to have all these incidents that are, you know, depending on your company, like very damaging to you. And so just being able to think about in the timeframes, like what do I need to do now to create enough space and time do something better so that you can actually live both now, but also like, kind of in the next phase as well.

Patrick Gallagher: I think it's so powerful because of, every round of a fast moving company is it can be an existential... and the next existential challenge you face. And the ability to move through those in a really powerful way is, is really helpful.

man, we have so many more questions to try and squeeze in before we close up.

Creating "Room and Attention" & identifying your unique capabilities as an engineering leader

One more follow-up question about "room and attention." how have you identified things that you are uniquely capable of doing? For somebody assessing where do I spend my time, that is such a powerful concept to zero in on when you're identifying opportunity.

Will Larson: I think, Particularly for folks in like leadership roles both again, technical and kind of managerial leadership roles. But there should be stuff like if you look around, like no one else can really do or they can't do it nearly as well as you can.

And, you know, long-term what you want to do is you want to figure out how to make that not be true. Or like, how do I grow other people who can have these same abilities and experiences so they can do this instead of me. But, in the moment that's not true. And so I think looking around and understanding where those gaps might be.

So a good example of this might be like a hiring process. If you're a manager or a senior manager, probably the only person who can change your engineering hiring process is you. So you either need to like... if this is something that actually needs to be improvement, as I guess the first one, I can think about some metrics around like the process, et cetera... but if this is something that's important, then either you need to do it or you need to explicitly figure out how to create space for someone else to do it, and like cede your authority to someone else to work on this topic.

And so I think on the technical side, I think often you'll get people who are like the only approver or the only trusted approver for a given piece of code or given like style of change. Every database migration needs to go through the senior engineer who's the only person who's like trusted to review them or something like that.

And so I think in that case, like one, only you can do that work today. And so making sure you actually do that work to unblock the broader system. But then also, you're really the only person who can fix that so that more people can do it. And so making sure that any work you'd see that only you can do is like structurally like a weakness. And then the most important meta-work can do is like making that not be true. And then you like pause, you look around again and do it the same thing over.

And this can be, you know, lots of categories of work, but I think API design, often you'll be having one or two people at a company who are the only people who can do approved API design . Large architectural changes that can move to a new database a new service strategy or something like that. Availability strategy, something like that.

On the management side, like definitely hiring's a huge one. Performance management is another huge one. Compensation is another huge one where typically there's only one- ish person who can actually like, think about this sort of thing. And you either need to be like doing it yourself because no one else can, or finding a way to actually make room for someone else.

Conversely, there are things that many people can do, like sourcing most types of candidates. But if you're trying to hire like a really senior person, it's way more effective to have the CTO or the VP of Engineering do that reach out. So that's a good example of something that you could look at one way as like, "Hey, this is something anyone can do", but really no one else can attract and excite like the most senior talent the way you as the senior-most leader in your function can.

Jerry Li: So I would add one more thing to that list that you mentioned that is only you can improve or make yourself a better leader. So setting aside time to reflect and invest in yourself, because many leaders are so busy doing all the other things and not leaving time for improving or invest back in themselves.

Will Larson: I think that's a great one. I was talking to someone about A mutual acquaintance and they, their comment was like, "Oh, they've gotten hard to work with. They're just so busy that they're like pretty miserable to talk to at this point."

And I think a lot of us are not bringing our best selves to work. And unfortunately, we're getting there because we're trying so hard to be helpful or trying so hard to do the right thing or to have an impact that we actually really become much worse at the work we're doing than if we were doing enough less, that we had the energy to like, actually do a good job of what's still there.

Get projects unstuck and prioritized fast by "Lending Priviledge"

Patrick Gallagher: Will, I wanted to ask you more question and I also want to make sure that we had time to talk about your upcoming new book.

The last question follows some of the things that you mentioned around ceding authority, where I think this might be the opposite of that, which is the concept you talk about with lending privilege. As a leader or as a high level person within your company, the concept of lending privilege has some huge opportunities for benefiting, the engineering industry as a whole.

And so I was wondering if you could talk a little bit about what does it mean to do that and How do you think about that?

Will Larson: So I just put up an interview with Aaron Suggs who's a principal engineer at Glossier and he called, he said, one of the things he does that's really impactful is being a "frequent first follower" where oftentimes you'll have someone who's like, "Hey, I think we should do something." But people won't like mobilize around the idea until someone who is perceived to be important or influential is like, "that's a great idea!"

And so, um, what he called being a frequent first follower is exactly what I mean in a lot of cases around lending privilege. Where there's something that someone is already doing. But they just can't make headway on it. It might be that if you want to like, buy like a thousand dollars of something, like the experience of doing that, if you are an executive, is you like wave at the FP and A person like "Hey we're, we're definitely buying this!" and then if you're an engineer you might go through like four weeks of like vendor, approvals or something, right?

And so organizations you know, create a lot of structure to prevent change. But it's easy to often, like not notice it as, you get more senior cause like you're exempt from it. You're like, well it's actually like pretty easy to get something approved. You're like, it is for me. But it's definitely not on average.

And so like looking at folks who are doing great work, but are just stuck in the systems that we kind of have embroiled them in. And obviously if we can, we should try to fix this so like it's not so onerous for everyone to do work.

But fixing is challenging, right? If you even think about like vendor selection there's a lot of like negative externalities to a company for each additional vendor they bring on. And so they, they really don't want to make it easy to bring on a lot more vendors. So like saying we should "fix the process" is like, not even clear what that means, Should you have more or fewer? Like, eh, actually, who knows?

But what you can do in that moment is like seeing a project that you believe is really important and someone's leading it. They're just getting stuck somewhere on these processes or systems and you can go lend your privilege, like help cut through all of that.

And, you know, sometimes it's things like process, but often it's not process related. It's like convincing a couple of the longer term engineers who don't like to change the systems much, really are comfortable with how they work. Spending some time talking to them about why we should take some risks. And why even if it fails to try it a different way, it's still better than not trying a different way at all.

Helping people get like time prioritized. You can bring some attention, like in terms of like things that have room and attention. Like attention can be created, particularly if you're senior, that you can create attention. And so if someone's doing some work the company doesn't value, you can go like, just chime into their managers. Like, "Hey notice so-and-so's doing like amazing work. I think this is really important." And all of a sudden, like this task, that all of a sudden had room, but no attention has like room and SOME attention. And those are some of the ways you can create privilege.

I do think this is extremely high impact work that is easy to do once you start looking for it. But a lot of folks, I think just don't think about it and just lose out on this like, amazing way to be really impactful. That is, is pretty quick.

Why Will wrote his new book - "Staff Engineering: Leadership Beyond the Management Track"

Patrick Gallagher: Thank you.

We know you have new book coming out, "Staff Engineering: Leadership Beyond the Management Track." Tell us a little bit more about the book. Why did you write it and what is the impact that you want it to have?

Will Larson: Yeah. So this has been a pretty fun project, I think have really benefited from a huge number of folks who've been willing to share their stories with me about their experiences. But when I look at the industry, I think one of the most frequent problems I hear from managers is like, "Hey, I don't know how to coach my senior engineers, like my staff, my principal, my distinguished engineers..." and then they're like, "Hey, like I just don't feel like my staff engineers, are like working at the level, I want them to ..." and then, you know, like kind of this dissatisfaction and often like a distrust of their senior, like engineers.

And then we've talked to like senior engineers like, "Hey, I can't get into rooms, to actually be involved in the conversations. I have no authority because the managers, they keep all the authority. There's really important work that I know needs to be done. But no, one's listening to me about why we need to do it. "

And I think you can kind of look at those and it's a mess. But I think it's a mess, like largely due to a lack of understanding of what the role is and the lack of like resources about how to build some of the skills to do the role.

I feel really quite like, sad in some sense for the folks who, whose managers are trying to coach them, but I've just never worked with someone in a role like this before. Or folks who are the first staff engineer at a company and haven't done it before themselves. Like, I feel like they're basically abandoned to like, imagine what the role is from scratch.

And so my hope is that creating a resource like this. That you can like learn from other folks of how the roles work And learn a little bit from that, because I think there's this, idea of architects being like terrible people. There's no title industry, like more widely hated than architect. but, But it's totally unfair! And it's like, architects is actually a really useful role. And a lot of the folks I spoke to are in architecture roles, but not labeled as architecture typically. Because there's this like stigma around it but I really think this is like a role we want and that's just one kind of archetype of staff engineer, but we sort of like blamed our poor execution on the concepts .

Like architecture and architects is a beautiful idea that's incredibly high impact. We've just done it fairly poorly and then pretended that it can't be done well. My hope that we start getting a lot more folks in senior roles who we trust and who we empower and who we then hold accountable for the work we're doing. And so that's sort of my hope for the project. And, you know, we'll see, we'll see where it goes.

I don't know if it will quite get there, but that's the, that's the dream.

Patrick Gallagher: That's wonderful and really excited for people to dive into your book.

Will, I think, all of us are on a quest to figure out how do we better use our time on the finite amount OF time that we have on this planet. And so just thank you for spending YOUR time helping us better optimize and focus on the things that actually matter.

Will Larson: thank you so much for having me. It's been a pleasure.

more to listen
Discover
EventsVideosSpeakers



Get social

Copyright © 2024 ELC. All Rights Reserved. / Privacy Policy / Code Of Conduct
ELC logo
Home for engineering leaders