Calm’s Will Larson on how to build a technical leadership career
There are plenty of resources and advice on unlocking the secrets of the engineering management career path. But what if the manager role is not for you?
That question has been on Will Larson‘s mind for a long time. For those who don’t know him, Will has over 10 years of experience in the likes of Yahoo, Digg, Uber, and Stripe, and he’s currently the CTO of Calm, the mindfulness app that helps millions of people to lower their stress levels and sleep better. As it turns out, he’s also quite the writer – since the last time we spoke, he has published not one but two books on engineering.
After writing An Elegant Puzzle about the challenges of engineering management in high-growth organizations, his focus shifted to a career path that’s much less understood – the technical leadership track. And while it’s true we’ve done a lot of work towards advancing the careers of individual contributors, there’s still a long way to go. If you’re a senior engineer and want to further your career, what skills should you develop? How do people move into staff engineering roles? What’s the right way to do this in your company? With his latest book, Staff Engineer, Will is hoping to answer all of these questions.
In this episode of Inside Intercom, Brian Scanlan, our own Principal Systems Engineer, sat down with Will to talk about all things staff engineer – what it is, how to get there, and what happens when you progress beyond a senior engineering role.
If you’re short on time, here are a few quick takeaways:
- To become a staff engineer, you can’t just rely on advice from your manager or company. They likely don’t have all the answers. Chat with other staff engineers and ask them how they got there.
- Different companies have different kinds of needs as they grow, and so the role of a staff engineer can take different forms. Moving forward in your career, avoid the trap of doing work that feels high-impact, but it’s actually not, or work that makes you look good at the expense of the project and the team. It may feel as if you’re on the right track for recognition, but most times, it’s not actually helping anyone.
- The key to doing meaningful work comes from a deep understanding of what the company values the most – that’s where you’ll find the room to do high-impact work.
- Will finds that writing a promotion packet is a good way to navigate the path towards becoming a staff engineer. Write a draft, talk through it with your peers, your manager and other staff engineers – and don’t forget to ask for feedback.
If you enjoy our discussion, check out more episodes of our podcast. You can subscribe on iTunes, on Spotify, or grab the RSS feed in your player of choice. What follows is a lightly edited transcript of the episode.
Solving the puzzle
Brian Scanlan: Will, we’re delighted to have you back on the show today for your second appearance on Inside Intercom. You last chatted with us way back in 2018, when you shared your insights on engineering and infrastructure management. For anyone who missed that discussion, do you want to jump back and share a bit about what you’ve been doing with your career to date?
Will Larson: I would love to. When we chatted at that time, which feels like a long time ago, it was really focused on this idea of infrastructure management, and I was working on getting together my first book, An Elegant Puzzle.
Since then, I hit my four years at Stripe and joined Calm a little bit over a year ago as their CTO. I’ve been given the opportunity to change my focus a little bit, from infrastructure engineering – which I think is some of the most interesting work that folks get to do, but also a little bit decoupled from the business itself sometimes – to thinking a little bit more holistically.
“On the engineering management side, I think there’s a pretty well-understood career ladder”
I also happen to think about this problem of what a staff engineer is. On the engineering management side, I think there’s a pretty well-understood career ladder. Managing director at the hedge fund Two Sigma, Camille Fournier, really explores that in her book, The Manager’s Path. But what do you actually do as a staff engineer? What is a staff engineer? This is the problem as they sort of try to give advice to folks. Well, of course, they know what a staff engineer is, but I didn’t actually know what a staff engineer was. So, I spent some time talking to folks about what they’ve done, learning from them, and trying to bash that all up into some learnings.
Brian: Great. Since we last spoke to you, you’ve published not one but two books. How do you approach your writing projects, and do you actually want to be a writer when you grow up? Or does this whole tech career thing support the writing? Do you think you have to be a practitioner in tech to do the kind of writing you’re doing?
Will: Yeah, that’s a great question. It’s funny, my sister is an actual author. My sister is a graphic novelist – she writes graphic novels, she sells graphic novels, and her career is centered on this idea of writing, illustrating, and selling these books. And that sounds incredibly stressful to me because I don’t know how you actually sell enough books of the right sort. I’m just faking it a bit relative to what I think a real professional author is doing. I get to focus on problems I’m really excited about, learn a bunch about them, and then try to turn that into a book versus the profit mode, which sounds extremely threatening. I think my books have done fairly well, but if I was trying to live off my books, I would be doing very, very poorly indeed.
A tale of two career paths
Brian: Your most recent title has been described as a pragmatic look at attaining and operating in staff engineering roles and staff-plus roles, building on the lived experience of folks who are doing the job. Why do you feel that it needed to be written, and who were you writing it for?
Will: When I first moved into management, it was at Digg. And Digg is an iconic brand, really amazing products in its time. But when I became a manager at Digg, it was a failing company where all the other managers had quit. I was the only manager, and I definitely didn’t know what I was doing. It was a very intimidating moment. Going from that moment where I was managing folks but utterly clueless and unprepared was really the center of my first book, An Elegant Puzzle. What do you actually do? How do you actually make some of these challenging managerial decisions?
And then you think about staff engineering, and it should be a totally different situation where every staff engineer I’ve worked with has had a manager, so that manager should be helping them. Typically, you don’t start introducing this role until a company gets to at least a moderate amount in size, so they should have a peer group. But when you actually talk to the staff engineers, many of them, I think, don’t know what their job is, don’t know how they’re evaluated, aren’t sure what they should be focused on, and aren’t sure how they should spend their time.
“We really underserve folks who want to stay on the engineering path. They just don’t know what they should be doing and how they’re being evaluated”
As I talk to more and more of these folks, there’s a bit of a crisis where they have two career paths. You can stay in engineering, or you can go into engineering management. But as I talked to more staff engineers, it became clear that we really underserve folks who want to stay on the engineering path. They just don’t know what they should be doing and how they’re being evaluated. In most companies, you can get a passing performance score by being well-loved. These are professionals who want to do a great job, not just be passively good. And they just didn’t know what to do.
All of a sudden, you’re actually managing and are responsible for a bunch of staff engineers. They’re asking you questions, and you just don’t know what the right answer is. I just didn’t know what to tell folks and it was my responsibility to be supporting their career. I felt like I couldn’t do that very well, and that’s when I wanted to really focus on this problem. How do I do a better job of supporting and helping the staff engineers that I worked with?
Brian: One of the most interesting things about the approach to the book was how important the crowdsourcing part was. Getting people to tell their stories wasn’t just part of your research work – it was part of your book as well. Do you think this approach to writing books in tech literature is a thing that you can reuse, or that should be reused as a way of exploring different types of roles or areas in technology?
Will: One of the interesting things about writing a book is that you have a position, you have a set of beliefs about how something should work. And how things actually work, what you’re writing, are probably a little bit separate. Because what’s the point of your book if it’s purely just describing reality? You’re sort of trying to describe reality but also pull the industry in a certain direction.
When I started this book, I had experience working with staff engineers, and I’d seen a lot of the challenges. But I didn’t want to give wrong advice based only on what I had seen. I really wanted a pragmatic book, because I think a lot of the advice you get if you’re a staff engineer, or let’s say you’re a senior engineer and you want to become staff, is what your manager’s obligated to tell you, but is sort of known to not be true.
“As the industry we’re in gets older, lots of folks are trying to develop themselves without moving into people management”
A good example of this is how to become a staff engineer. Every company has a series of points they will tell senior engineers, but often, if you follow those points directly, it’ll be very challenging to become a staff engineer. The company has different challenges: they need to manage a certain ratio of staff to non-staff folks, so they have the right budget obligations, et cetera. You can’t just listen to what the company is telling you. You have to listen to the other staff engineers who have actually made it and understand their stories as well.
In terms of whether we should do more of these books, it’s a good question. I don’t know. I started this project maybe around two years ago, and since then, a technical program manager (TPM), has reached out to me like, “Hey, I want to start doing a similar project. I don’t know what a TPM is, and I’ve been a TPM for almost a decade, and no one can tell me what a TPM is.” I talked to a staff designer, reached out, and actually staff.design is a website with interviews with staff designers, and it’s like, what is a staff designer? Does a designer have a second career path, or do most designers have to become managers to continue their careers?
But you know, it’s not just them. Take product managers. What does it mean to be a product manager who is not a people manager? Can you actually succeed in that role? I don’t know the answers to most of these, but I do think it’s interesting that, as the industry we’re in gets older, lots of folks are trying to develop themselves without moving into people management. And generally, people don’t know what that looks like, even though we’ve said that we’ve solved it by offering a second career path. In reality, I think folks still mostly aren’t sure how to navigate it.
The four archetypes of staff roles
Brian: Great. So let’s dig into your book, Staff Engineer, a little more deeply. In the book, you outline four archetypes of staff roles and staff-plus roles. Architect, Tech Lead, Solver, and Right Hand. Could you tell us a bit more about each of these roles, and what they look like in practice?
Will: So one of the core problems with staff engineers is, what is a staff engineer? If you talk to people at seven different companies, you’ll see some overlap, but also a lot of things that don’t overlap at all. I was trying to figure out how to describe them in a way that acknowledges that different companies have different kinds of needs, and so, you have different staff engineers. Facebook actually has this idea of, I think, five archetypes, which is kind of their level. They’ve developed this into their own set of representations of what makes sense for them. But as I talked to more different companies, I kind of settled on these four in terms of different ways different companies have needs that represent the role of the staff engineer.
“If you look at our industry, some of these ideas are really well understood but have fallen out of favor”
If you look at our industry, some of these ideas are really well understood but have fallen out of favor. Take architects. When I first started my first job in the tech industry, it was at Yahoo. And over a certain level, I think it was maybe the fourth level, everyone became an architect. And then they’re like a senior architect, a principal architect, then a senior principal. I think there were 14 levels – the first three were engineers, and then there were 11 levels of architects or something.
But the idea of architecture has not remained popular because many of the people fulfilling these architect roles did it in a way that was very top-down, which doesn’t represent what we’ve learned about leadership since. But the work is still there, it still needs to happen. So I wanted to think about how we talk about what these people are doing, but in a way that’s a little bit more about decoupling the role from level. And that’s how I ended up with these four.
Just quickly, the architect is usually someone who’s responsible for a given area. So, they’re often going to be a director, a senior manager, and they’re trying to figure out how to make all the decisions in a given area, say databases or networking, or it could be front end, in terms of the user experience (UX), or maybe IOS engineering. It could be any of these different areas. And it’s really thinking about the quality of the code in that area.
The tech lead is typically someone who’s tagged to a specific team as partnering with them on whatever they’re trying to do. Solvers tend to be reactive to what leadership is really worried about. For example, “Hey, there’s a GDPR deadline, and we haven’t done any GDPR work, and we’re about to be screwed in two months. How do we fix it?” And so, I think most companies at a certain size have teams or individuals who are just able to pivot to whatever the leadership is really concerned about. It might be reliability, it might be a compliance issue, it might be a competitive threat, whatever. And these folks are real and important, but often they’re kind of ignored because they don’t fit into this team structure that we typically use to think about larger organizations.
“Staff engineers are leaders, whether they’re doing any of these different archetypes, but they’re not managerial leaders – they’re their own different type of technical leadership”
And the final one is this right hand, and I think this is an important construct because a lot of companies have folks who have some random title, often a staff engineer, but they’re almost not doing what we’d consider to be technical work, in some ways. They’re almost doing the same work that the manager is doing, but they have no direct reports. And we need to find a way to acknowledge these folks, and so I talk to Rick Boone, Senior Software Engineer and Strategic Advisor to the Vice President of Infrastructure Engineering at Uber, who’s a great example of this. I also talked to Michelle Bu, Payments Products Tech Lead at Stripe, who is partnered directly with a senior leader and is taking a lot of their leadership tasks. And this is where I think this idea of management versus leadership gets really interesting, where staff engineers are leaders of the companies, whether they’re doing any of these different archetypes, but they’re not managerial leaders – they’re their own different type of technical leadership.
Brian: If I look at Intercom, I can definitely see folks, probably like myself, who are doing the architect role. There’s definitely tech leads in our groups. Maybe a couple of solvers knocking around, as well, but we’re probably not big enough yet to have that kind of right-hand person. In terms of the distribution of these types of archetypes, do you think there is a relationship between the maturity or the size of the organizations that they’re in?
Will: I think there are two different things that matter a lot. The first is whether teams are strong teams or weak teams. In some companies you talk to, teams are really central: work belongs to teams. People have joined teams and there’s a manager who organizes the team. In some companies you talk to, teams are actually quite weak, where people flit in to work on a team, work on it and then flit out. When you talk about who owns your messaging system, and you’re like, “Oh, Ellen owns it.” And it’s not the team that Ellen’s on – it’s Ellen individually who somehow owns this entire technical system.
I think solvers primarily exist in this second world where there are kind of weak teams. And different companies solve problems in different ways. Most companies, as they grow, start to have a strong team concept, just because it’s incredibly hard to run an organization with 300 people without teams as a bit of an abstraction. But some companies go quite a long way before they have strong teams, and typically, it’s only when you hire a strong managerial leader that you start having strong teams.
The right-hand construct, to your point, I think I’ve typically seen it when engineering gets over 1000, although some companies roll it out a little bit earlier. Often, it’s a sign that their structure is actually not working that well. But typically, by the time you have 1000 engineers, you’ll start to see a few people operating this role even if they’re not labeled this way. By the time you start to have many thousands, there are probably quite a few folks operating this way. But they might be called literally anything, and so finding them can be a little bit challenging.
The core challenges of leadership roles
Brian: There are lots of different shapes and people should be playing to their own strengths and what is really important to the organization at the time. But some common pitfalls you identified in the book might blow people off course, maybe make them less effective in the role. Could you go through those for us?
Will: I think one of the core challenges of leadership roles is that, early in a career, you know the most important thing is getting this migration done or launching this product feature. Someone will tell you that. But as you get more senior, people don’t really tell you what you should be doing. They just grade you based on what you’ve done and whether it’s important. And this is a really confusing transition, where you go from knowing exactly what to do and how you’re graded to getting graded based on the perception of whether the work you’re doing is important or not. And often, that perception takes months or sometimes years to actually flip its way to you. It can be quite a confusing moment, and I think that’s what leadership is, no one’s telling you what to do, but they’re still grading you on what you’ve done. And it’s kind of a frustrating moment to figure out. How is this reasonable? And whether it’s reasonable or not, it’s real.
And so, I started thinking about the ways that folks that I’ve seen, who are really talented, get stuck when they try to make this transition to setting their own goals. Think about this idea of snacking. Hunter Walk has a great article about this that I kind of took this idea from. Often, when you don’t know what to work on, you’ll start working on stuff that just feels impactful. And often, stuff that you used to be really good at or that used to be really impactful, may no longer be that impactful.
“This might feel really good and productive, but you’re probably only pissing off all your peers, you’re not accomplishing something particularly noble”
A good example could be going to incident reviews and being very critical of the proposals of how we’re going to fix problems. This might feel really good and it might feel productive, but you’re probably only pissing off all your peers, you’re not actually accomplishing something particularly noble. But some folks will hide in that work because it feels rewarding.
Another good example is from my own personal experience at my last job at Stripe. I was a little bit frustrated with a few things, so you know what I’ll do, I’ll start a manager book club, and we’ll read some books, and we’ll invest in the leadership of tomorrow. And it felt successful, we got the book, we all started reading it, we talked about it. But does this address any of the problems I was supposed to be fixing? Absolutely not. I was just doing something that made me feel better in the moment. And I think it’s easy to fall into that. It’s very comfortable. And there’s a prebuilt narrative about why it’s the right thing to do, but the narrative is obviously wrong to the people evaluating you. And you have to recognize when you’re hiding at that moment.
Another one that I think about is preening. There’s a lot of work that is high status but low impact. The kind of instant reviews is a great example of that – simply by being present and having a loud voice, in some companies, you’ll be perceived as high status and high impact. But as you look at whether your voice is being listened to, whether it’s actually changing what people do, you can often see that it’s very low impact. Typically, going and being negative is perceived as high status, no matter where you are.
I think it’s important, once you get into senior leadership, to be thoughtful about where you are negative because you can go into a product planning meeting and shoot down all those ideas, and they’ll be like, “Oh, this is a real leader, not letting us get away with sloppy product thinking.” But if you just stop them from moving forward, all you’ve done is sabotage. You actually haven’t helped. You’re doing work that makes you feel or look like you’re high status or important, but the actual consequences are that the business gets slower, you can’t shift things, and you’ve demotivated the people you need to be leading.
And the last one I’ve talked about is this idea of chasing ghosts. When you talk to folks, particularly from other companies, they tend to bring the number one problem they had. They often superimpose it on the new company they’ve joined. And particularly, if you are someone from Facebook, Google, or Apple – the problems you have at a 100,000 person company versus the problems you have at Intercom, where you have hundreds of people, or at Calm, where you have 150-200 people, are just radically different. You have the same data locality problems at both companies, but at one company you might just be like, you know what, we’re just not going to solve this for a couple of years. Whereas at an Apple, you might literally have to solve it immediately. Just make sure you are solving problems that actually exist.
“I see folks waste a ton of their own and their organisation’s time by chasing after things that were a huge problem previously, and just assuming that they still are”
I think something that happens for senior leaders who come from a large company and come to the new company in an even more senior leadership role, one of the ways to be perceived as a leader is to have conviction around where the problems are. And this is where I sometimes see folks waste a ton of their own and their organization’s time by chasing after things that were a huge problem previously, and just assuming that they still are. When in fact, at a small company, the real problem is usually something that is nominally quite simple but in practice quite hard to solve.
Brian: A lot of that resonates, I think I’ve been guilty of probably all of those things.
Will: Me too.
Brian: Before Intercom, I came from Amazon, and I certainly had to kind of deprogram myself to not try to solve Amazon’s problems at Intercom. And one of the areas I work in is AWS cost management, and snacking there is so easy. You can save a few dollars here and there, and it’s real, the money is real, but it’s not really impactful, and it’s certainly not a leadership staff-type challenge to go in and shut down a few unused EBS volumes or whatever.
Will: It’s also very easy to be critical about the AWS cost management, like the database team isn’t prioritizing saving money on these databases or something, or you’re absolutely right, but it still might not be the right thing for them to do. But by accusing them of it, you claim the moral high ground very quickly and are perceived as the leader even if you’re wrong.
Doing work that matters
Brian: We’ve gone through a few things we shouldn’t do as staff engineers. What’s the work that people should be actively seeking out to do or the type of work they should be going after?
Will: I think this depends a little bit on the archetype that your company actually wants from you. One of the core challenges is decoupling what you want to do, what the company actually values from you, and centering the majority of your work on what the company values. If there are certain things that are very important to you that the company doesn’t value, you can still do that work, but you shouldn’t be surprised when the company doesn’t value it.
Don’t set yourself up where the company needs to value team-building or investing in leadership or mentorship and you convince yourself that they’re going to value it because you care about it. Ninety-nine percent of the time, the company knows what it values, and even if you did a great job around mentorship, it may still not value mentorship. You still might want to invest there, but you shouldn’t invest there thinking that you’ll change the company’s structure and value systems. You probably won’t. Own the choice but don’t get upset about it later.
That’s the first idea, where is there room to actually do work? If no one’s doing mentorship, there might be a lot of room to do it. And attention – the company actually cares about something. Noticing those moments, that’s the biggest opportunity for someone in the leadership role or the staff role to actually do something really impactful.
“The room to do the work has been there for a long time, but the attention, the agreement that this is actually the thing to be focused on, didn’t exist”
A good example is something that happened at Stripe, and I think at every company – there’s a moment when management goes from, “Oh, managers are kind of useless” to “Oh, I wish we had really great managers, we needed them a long time ago.” It’s that moment when, all of a sudden, this leadership, this mentoring, this cross-functional investment coordination, goes from being unvalued to valued.
All of a sudden, there’s a ton of high-value work because the attention just showed up. The room to do the work has been there for a long time, but the attention, the agreement that this is actually the thing to be focused on, didn’t exist. And so, make sure that you build that agreement, or just fail at building it and don’t do it until there is actually the room and the attention. That’s the first thing I’d think about it.
And it’s not just management. Reliability is another one where, at a lot of companies, they’re like, “Hey, the way we’re deploying is pushing a lot of bad features to our users that don’t work, we’re learning about problems in production from our users. How can we fix it?” You can push on that, but until the company thinks that’s a problem, it’s extremely hard to make progress on it. Infrastructure costs are another great one. Many companies are like, “You know what? Infrastructure costs don’t matter at all.” And then, all of a sudden, this moment switches and it’s urgent panic, “Why are we spending so much money on AWS?”
“If you do the work at the wrong time, it’s really hard to get the buy-in from other teams because leadership doesn’t care”
If you do the work at the wrong time, it’s really hard to get the buy-in from other teams because leadership doesn’t care. But then there’s this subtle moment where something switches – maybe you’re trying to be profitable to go public, maybe the amount you’re spending catches the eye of your Chief Financial Officer (CFO) – where all of a sudden there’s a ton of energy and attention. Noticing those moments is really important.
A few of the other things that I think are worth pulling out are first, investing in the org around you. If you’re not sure what to do, figure out how to grow other folks so that you’re not the only person able to do something, list the things that only you can do and then figure out how you can get one other person to do all of those over the next year – that’s incredibly high-impact work. Often folks will do really great work, like a great design doc or something, but there are a few wrong things. If you can give them some advice early on, they can save weeks or months. So figuring out how to bring your experience and share it with other folks in a way that’s supportive, enriching, and growing of them, it’s really powerful.
Often, you’ll find projects where you, personally, if you’re responsible for something, you can just finish it and move on to something else. But the person who’s responsible for something might be finishing a migration, maybe they’ve been trying to move over from PostgreSQL to PostgreSQL Aurora for the last year, and they just can’t get four things moved over for some reason. If you just put your thumb down on it a little bit, you can help them finish that in a week. Where, if they try to do it themselves, they might never be able to finish it because they just can’t get someone to listen and actually do a relatively small amount of work to make the shift.
Finally, what are the things that literally no one else in the company can do? For example, you might find that you don’t have a strategy for your infrastructure group, or you might be missing a strategy for one of the product sections, and some folks will probably agree with that. But they just won’t have the organizational trust to actually fix the problem. I think this is one of the interesting spots where you, as you move into the staff leadership role, are able to address certain problems that, even if others can see it, they just can’t make progress on.
Navigate ambiguity with promotion packets
Brian: Great. There’s a lot of great advice on progression in the book. And what jumps out to me are the ideas you’ve shared around promotion packets. This stuff is useful and not just for engineers, or not just people looking to move to staff. Why did you include this in the book?
Will: In the best case, you have a great manager who knows what you need to do to get promoted and will just support you, and give you feedback, and will be there from the start of your journey to staff through the completion of that. But most people don’t have the best case, in some way. Your manager might get promoted out of the role they’re in, where all of a sudden you’re almost promoted to staff, you get a new manager, and you’re like, “I’m almost there,” and they’re like, “Well actually, I don’t see any of that.” And you lose a couple of years and that promotion. Or you get acquired. Or you and your manager have a falling out, you switch companies, and you start rebuilding.
These are just problems that can happen with you and your manager. When I was at Uber, I used to be senior, and then became staff. Then all of a sudden, they had senior one and senior two, and then staff. And so, people who thought they were going to get promoted to staff in six months, all of a sudden it took them four years to get promoted to staff because they had to get promoted from senior one to senior two, and then from senior two to staff. All of these things can happen that can get you derailed.
And again, it’s going back to this idea that, on the leadership level, the folks who will give you the clear direction start disappearing because no one actually quite knows the clear direction. The promotion packet is a way to help navigate the confusion and the ambiguity and the change that happens. The core of it is, write the promotion packet for yourself. Run it, talk it through with some of your peers. Talk it through with some folks who are already at the staff level. Talk it through with a manager, your manager, whoever that might be. And just use it to actually focus on the feedback you’re getting.
“These rules of thumb show up from nowhere. And you’re like, ‘This isn’t in the ladder. How am I supposed to know that?’”
For example, a lot of times, someone is about to get to staff level, but they keep getting rejected because, “Oh, is the impact of their work large enough?” or “Well, the project they did is great, but we need to see it run for a year in production to know if it’s actually stable or not.” And these rules of thumb show up from nowhere. You’re like, “This isn’t in the ladder. How am I supposed to know that?” And you can again be upset that you’re getting randomly surprised by these things, but what I found is you can usually uncover them ahead of time by using this promotion packet strategy. Share the promo packet pretty widely with your manager and get their feedback. If you take ownership of it, write the packet and get feedback on it, you’ll be able to figure out where the gaps are. If you don’t, you’ll often get surprised. And you can be frustrated about it, but if you want to be a leader, a big part of it is taking ownership for yourself.
Brian: Cool. What are the important areas that people should be looking at when creating their packet when they’re trying to move to staff? One thing that I tend to try to de-emphasize is the mythical staff project. It’s like, you just have to achieve this one piece of work, and suddenly, you’re staff. I think that doesn’t really work, but it’s easy for people to get focused on that sort of stuff. I don’t know if you agree with that, but what areas do you think people should be focusing on if they’re looking to write this packet and get the staff?
Will: First, the staff project is a really important question. I think there is a myth that the staff project is the most important. And some people out there are repeating this myth and believe it really strongly. But as I talk to more and more staff engineers, the majority of folks I’ve spoken with didn’t have a staff project. This is a case where the promotion packet’s actually really powerful because someone will tell you that actually, to get promoted, you need to do a staff project. But as you run this promo packet with a few other people, the majority of them will either say, “Actually, most people don’t have a staff engineer project at all.” Or they’re like, “Oh, I actually never did that.” And it helps to understand what’s real because there are these kinds of ideas, these quips that people share to try to explain why people can’t get the staff that are often just wrong.
In some companies, though, they really do center on this idea. So, it’s important to figure out not what should be true or what’s true on average, but what’s true for your specific company. When I spoke to Ritu Vincent, Engineering Manager at Dropbox, Dropbox really did center on this idea of having this staff project. So, no matter what the norm is, knowing what’s true for your company is more important than knowing the norm. And the packet is a great way to figure that out.
“Every company is a little bit different, and I think the value of the promo packet is to start figuring out what your company actually cares about”
Every company is a little bit different, and I think the value of the promo packet is to start figuring out what your company actually cares about. Don’t worry too much about what you think they should care about or what the norm is. Figuring out what work you’re doing that’s really valuable and easy to miss is one of the things the promo packet can be very helpful for. There can be stuff that you’re doing, supporting other users and supporting folks in the company that your manager just never sees. Make sure there’s visibility for the work that you’re doing. Cross-functional work is especially easy to miss.
I think there are definitely ways to claim impact. In fact, at companies where they’re very focused on impact for staff promotions, you’ll find four people who are like, “Oh, I shipped this one project.” Well, what actually happened here? All four of you didn’t lead this project. And it can be really confusing. Often, in these promotion calibration meetings, you’ll have three managers arguing about who did what on a given important project, none of whom were directly involved in the project. And so, the packets can be great at clarifying who actually did what work.
Another area that I think the staff ladder has that can be pretty confusing is mentorship. It’s like, “Hey, you have to mentor a number of folks coming up.” But I’ve been at companies where it came out in the calibration sessions that folks who were getting mentored felt quite negatively about the experience, but the person who was mentoring was like, “I need to do some mentorship to get promoted, I will accomplish some mentorship.” And they sort of pushed this advice on someone else and then got promoted for it.
Having the promo packet is a great way to not do that to someone. You can actually make sure your manager or someone is getting the feedback from the people you’re mentoring that it’s positive. But if you are doing it, the promo packet is a great way to discover that while I thought I was doing this great job mentoring, I was actually taking advantage of someone to get promoted.
A place to find community
Brian: Before we finish up, one question we like to ask people on the podcast is if there’s somebody in the industry that you aspire to or are inspired by.
Will: In terms of who I aspire to be, I don’t think I know that one. There are just so many folks creating their own paths, and I really want to do my own thing. I am grateful for my time at Stripe, I learned such a tremendous amount there. I learned so much at Uber. I’ve learned so much pretty quickly at Calm, but there’s still so much more for me to learn. And there’s the writing component. I don’t know if everyone should spend time writing, but for me, it’s been a great way to solidify what I’ve learned relatively quickly.
Thinking of folks who are inspirational, the thing that’s probably been most impactful for me is that right before I started my job at Calm, I put together this learning circle. We meet every two weeks, and there’s a bunch of folks who are VPs in engineering, a bunch of folks who are CTOs. We just talk about the challenges facing us, and that group has just been incredibly helpful for me. Something I’ve learned from them is that the problems that feel unique are actually pretty uniform. Everyone is dealing with the same set of problems over time. That could be hiring, figuring out how to partner successfully with different functions, that could be a strategy, that could be how you let folks go in a small company because it’s really difficult.
“If you don’t have a leadership circle, a place to find a community, that is something that I would highly recommend to everyone”
Everyone in that group has been kind of life-changing to spend time with. If you don’t have a leadership circle, a place to find a community, that is something that I would highly recommend to everyone, to figure out how to build that. I think people are just sort of desperate for learning circles, so if you don’t have something like that, I think what a lot of folks do is reflect on not having it for years. But if you reach out to fifteen people who are doing a similar role and just suggest a meeting every couple of weeks at a certain time, particularly while we’re mostly working from home, it’s surprisingly easy to do and really impactful.
Brian: Awesome. Lastly, where can our listeners go to keep up with you and your work?
Will: Yeah, if you’re interested in the staff engineering idea, just come to staffeng.com. I’ve been a long-time blogger for a little over a decade now on my blog Irrational Exuberance.
Brian: Great. Thank you so much for being on the show, Will. It’s been great talking with you.
Will: Thank you so much for having me. It’s been fantastic, and I hope to be back with another book in three to five years.
Brian: Great, we’ll talk to you then.
