This story was recorded in May, 2020. Learn more about Bert on his blog, Twitter, and Linkedin.
Tell us a little about your current role: where do you work, your title and generally the sort of work do you and your team do.
I’m a Senior Staff Engineer on the Platform team at Slack. I was lucky enough to join Slack shortly after we launched the Slack App Directory so I’ve had the opportunity to help evolve the Slack Platform into what it is today.
It’s hard to generalize the work that I do but the goal is always the same: enable developers to build on top of Slack to make our customers’ working lives simpler, more pleasant, and more productive. Examples of this include building new platform features, improving API performance, writing documentation, and working with partners, internal integrators, and third-party developers to ensure that they can build impactful software.
What does a “normal” Staff-plus engineer do at your company? Does your role look that way or does it differ?
The work that Staff-plus engineers at Slack do is incredibly varied depending on which part of the company you’re in, the composition and size of your team, and what the business needs from you. Staff-plus engineers are often the tech leads of projects, which means that they help write the tech spec, get feedback from various stakeholders, work closely with design and product to decide what to build, and lead the technical implementation for the project. They also mentor other engineers, improve our interview process and engineering culture, develop engineering processes and tools, and provide technical direction for refactors and tech debt. Staff-plus is all about enabling other people to do better work - to be a force multiplier.
My role includes all the things that I’ve mentioned but I tend to focus less on specific pieces of technology and more on what the technology is enabling. So I might spend time prototyping concepts that will almost certainly be thrown away or gathering usage metrics around a particular user flow to better understand how to improve the system. I will often build apps on top of the Slack Platform to keep myself honest about what the developer experience is actually like and actively try to build on other people’s platforms to see what works and what doesn’t. A lot less of the code that I write makes it into production than other engineers at the company and I’m completely fine with that.
Can you think of anything you’ve done as a Staff-plus engineer that you weren’t able to or wouldn’t have done before reaching that title?
I’ve done a lot of experimentation with various product ideas in the last year, some of which have evolved into actual features of our Platform. Part of the reason I was given the opportunity to do that is that I’ve established trust through other projects that I’ve successfully shipped, but having a Staff-plus title seems to bestow a little more flexibility in what I choose to work on.
For better or worse, I’m also in a lot of strategy and planning meetings I was never in before. If you’ve ever wanted to know how the sausage was made from a leadership angle, maybe consider if you actually want to know how the sausage is made.
How do you keep in touch with how things really work as you spend less time on hands-on development?
The best way I’ve found is to have regular 1:1s with engineers across the company and spend a lot of time listening. You can learn a lot about the current state of engineering if you take the time to develop relationships where engineers feel like they can be honest with you. As a Staff-plus engineer, you have no real influence over how much money someone makes or their next promotion, so engineers can be more candid with you if you make yourself accessible to them.
What two or three factors were most important in you reaching Staff? How have the companies you joined, your location, or your education impacted your path?
I come from a fairly privileged background - I graduated from college with a computer science degree and no debt or student loans and part of what that bought me was the flexibility to leave a job without worrying how I was going to make rent or if I was going to find a new one. And I leveraged that flexibility into becoming pickier and more strategic about the places that I wanted to work.
I acknowledge that most people don’t have that option but for me I thought it was important to work on things that I felt were meaningful - things that I personally used that I thought were having a positive impact on the world. And I believe those choices have paid dividends because companies like that attract like-minded folks who will go on to other companies that hopefully are aligned in the same way. This is not a meritocracy and your professional network is important. I’ve gotten jobs because I’ve applied on the company’s website like everybody else but I’ve also gotten jobs because I’ve awkwardly e-mailed a manager there that I haven’t talked to in years but that I respect and know that they respect me as an engineer. We work in an industry where there are a lot of options of how to spend your time and if you’re lucky enough to be in a position where you have the flexibility and privilege to choose, you’re doing yourself a disservice by not regularly evaluating what you work on.
Maybe at one point you’ll become the kind of engineer that when you announce on Twitter that you’re starting a new job, people who you’ve worked with before will create a calendar reminder for four years in the future when you’re fully vested so they they have the highest likelihood of poaching you, but until then, you’re going to have to write awkward e-mails to people that you would like to work with again.
Can you remember any piece of advice on reaching Staff that was particularly helpful for you?
The best advice I’ve heard is that often reaching Staff is a combination of luck, timing, and work. Here’s a path of events that I’ve observed and personally experienced:
- Develop a relationship with your manager where they implicitly trust you and you implicitly trust them. Be honest and direct with them about what you want. Developing this trust will require you successfully delivering on the things they ask you to work on.
- Because your manager trusts you, when they hear about projects that will have a significant impact for the company, they will advocate for you to lead those projects. Alternatively, you’ll have to find or create a project yourself and advocate for it to happen. This is much harder but still plausible.
- Deliver the project successfully.
- The project has a significant impact on the company.
- Because you successfully delivered a project that had a significant impact on the company, it’s easy to advocate for your promotion to Staff, which your manager is happy to do.
Hopefully you can see where luck and timing can affect this simple plan - what if you don’t get along with your manager? What if your manager leaves the company or gets promoted? What if you’re in an area of a company that gets no interesting projects? What if the project is doomed to fail? What if the project succeeds but has no impact?
These are all possible and there’s no generic piece of advice that I can give to overcome any of them except that sometimes you’re never going to get promoted and you should probably be honest with yourself and identify when you’re in that situation. In that case, sometimes the only way to get promoted would be to leave the company and do something else. You may boomerang back into the company at a higher level than you left at later in your career, but much like a failed relationship that you revisit, do you still want to be there or is there too much baggage to ever make it work?
What about a piece of advice for someone who has just started as a Staff engineer?
It’s kind of a running joke in engineering but a lot of people get into this profession because they don’t like talking to people but to be effective at your job as a Staff Engineer, you’re likely going to spend a lot of your time talking to people. I think you can progress early in your career by focusing on just writing better and better code but at some point you should probably shift to focusing on working better with other people. Trusting other people and giving them the freedom to make technical decisions (even ones that you disagree with!), understanding other people’s motivations, learning to give difficult feedback, knowing when to pick your battles - these are all useful skills to have.
If you haven’t already, try to become the engineer that people want to work with. There are a handful of engineers at every company who, if you ever left your job, you would try to circumvent a non-solicitation agreement to work with again. Become one of those engineers for other people and it’ll unlock a lot of doors for you in your career.
Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?
Early in my career, I once told my manager I was concerned that I would have to go into management at some point and they said something like, “Don’t worry about that! At this company we have two different tracks, the management track and the IC (individual contributor) track, and there are equivalent roles in the IC track for the highest management positions, so you’ll never have to switch to management in order to move up in the company.” While technically true, the omission that seems obvious to me now is that at a lot of companies, the management track is a lot less vague than the engineering track.
The higher up you climb in the engineering ladder, the less examples you’ll have of what to emulate and the examples seem more and more unattainable. When you start to dig into it, you may realize that someone had gotten the title when their company was acquired or they were the author of a programming language or framework or they unlocked tens of millions of dollars in revenue for the company.
A lot of my colleagues have gone into management for various reasons and I suspect one of those reasons may be the more obvious, reliable progression that I’ve described. But I believe strongly that that shouldn’t be your primary motivating factor. If you have open calendars, take a look at your manager’s schedule and the number of 1:1s they conduct a week. Is that a schedule that you would enjoy? The desire to write code isn’t black and white since there are tech lead manager positions where you write code and Staff-plus engineer roles where you never write a line of production code and spend the majority of your day in Google Docs or Dropbox Paper. But in my career, I’ve never had to lay someone off or deny them a promotion or write performance reviews - I know which side of the coin I’d rather be on.
