When working on Airbnb’s infra team, I struggled to grow from an L4 engineer to a senior/L5 eng.
I came early, stayed late, and said yes to working on anything that needed help - I was as eager as a new grad could be.
Eventually, I found myself on a project to migrate engineers across all of Airbnb off our old deployment platform, “Deployboard,” onto the open-source Spinnaker. My manager had a goal that in the next two months, 80% of micro-services would be deployed from the new platform. I coded relentlessly and did my best to uphold the highest quality bar. I fixed bugs, brushed up on my Java, and read textbooks on how to better review my teammates’ code.
Despite all my frantic efforts and sleepless nights, when my manager checked in with me at the halfway point, I realized I had no idea whether or not we were on track to hit our 80% goal. In fact, we were way off track, and I just didn’t know.
Later that year, I was dismayed to see a harsh performance review. My manager sat me down and explained: I had been doing the work of two L4 engineers, but that would never get me promoted to an L5. What he needed was someone he could reliably hold accountable to hitting specific project goals. Furthermore, if for some reason a goal couldn't be hit, he needed me to raise the blocker ASAP along with a new plan. I was so focused on solving the immediate problems in front of me, I didn’t see the larger picture. In return, he couldn’t trust me - at least not to deliver senior-level projects.
Despite my frustration at the time, this was the best performance review I ever received.
My issue was one of focus and reliability. My input effort meant little if I failed to land hard projects with grace. I could grind and execute as an all-star engineer, but my career would stall, and I’d never drive large-scale company impact.
Note
Greg spends full workdays writing weekly deep dives on engineering practices and dev-tools. This is made possible because these articles help get the word out about Graphite. If you like this post, try Graphite today, and start shipping 30% faster!
To be a senior engineer is to cultivate and maintain trust
L3 / Junior SWE: Can be trusted with small bugs and scoped tasks.
L4 / SWE: Can be trusted to drive large complex projects.
L5 / Senior SWE: Can be trusted to plan, coordinate, and deliver large complex projects.
In 2020 I quit Airbnb, moved to NYC, founded a startup, and coincidentally became a pandemic hermit. The sweeping life change was overwhelming, but gave me a chance to reset my working style. Graphite, in particular, forced me to adopt a more mature perspective on project ownership. Dependability became critical - first with my cofounders, and later with our engineering team.
Early on at Graphite, we knew we’d have hard engineering problems and minimal management oversight. In response, we chose to only hire senior engineers for the first ten folks. This made 2022 recruiting brutal, but had the positive effect of forcing me to deeply reflect on what makes an engineer “senior” - the same level I struggled to perform at just years earlier. While many factors contribute™️, I realized the core thing I need from a senior engineer is the ability to reliably ship challenging, ambiguous projects. I need to be able to trust them with broad problem areas and know they’ll deliver consistently without having to micromanage them.
Given that high trust has become a core expectation of all engineers on the team, I’ve also been forced to reflect on how to build and maintain trust. It’s only fair that if we expect it, we should articulate how to cultivate it.
Trust is a streak
Fundamentally, trust is how much someone believes that you’ll do the right thing, when you have the chance to do the wrong thing. This is also true in engineering projects: trusting that if you put someone in a situation where there’s a risk of failure, they’ll either navigate through the complexity and deliver, or they’ll provide direct, immediate feedback that something about the project needs to be rescoped so that success is possible.
As a practical example: when I meet a friend for coffee, I have some degree of trust whether they’ll be on time or not. Ideally they’re on time, but there’s plenty of opportunity for them to be late. My percentage confidence that they’ll be on time, is how much I trust them (at least in the realm of coffee meetings).
If I get coffee with someone new, all I can do is hope they show up on time. If they show up on time once, I have a slightly higher belief they’ll do it again the following week. But if they show up late the next time, my trust takes a dip. If they show up late 1/3rd of times, my trust becomes pretty low that they’ll show up on time in future meetings.
The person I trust most to show up on time is the the person who I’ve had coffee with 30 times before, and in each instance, they’re on time. It’s the person who’s always on time, and who, in emergencies, messages me when something comes up up. While it may just be coffee, the same person also does this with other engagements and other people.
The point I'm getting at is that I believe trust is mostly a game of iterations and streaks. The best way to build trust is to log repeated instances where things could go wrong but don’t. The longer the streak, the more someone will trust you in a future iteration. Break that streak however, and you suddenly find yourself needing to rebuild trust.
This is true for small things like showing up to meetings on time, but it’s significantly more important for critical software projects. All projects are useful, but some are higher stakes than others. If a refactor takes longer than the committed time, or fails to land - it’s not the end of the world. If we’re pivoting the company (as we did twice in the early days), I’m going to give ownership on the new functionality to the most trusted engineer in the room. And that person will be the person who has the longest streak of taking hard, ambiguous projects and shipping them reliably.
Trust = the belief, that given a new situation, someone will deliver.
Building trust = creating a streak of continuously living up to expectations and promises.
Trust in the context of engineering
First impressions matter a lot. If you're working with a new person, or joining a new team - I believe it’s worth going above and beyond to ensure you build a strong streak. More important than doing a ton of work, or doing something very hard, is reliably delivering on expectations. When you’re new, folks around you are subconsciously building expectations of you, and their prior examples may be sparse. This lack of context is why it’s so important to make their first few datapoints of you stellar.
Warren Buffet describes reputations as taking 20 years to build, and only a minute to destroy. I think trust can be similar - and the mistake I see is wonderful engineers not caring enough about protecting their reliability streaks. When working on a hard project, there’s always a chance for something to go awry. Unknown unknowns erupt, and the timeline needs to be pushed back. But what I need to trust in is that the project owner will immediately communicate the situation and handle the next steps with care and grace. Not just ignore the delays and wait until its too late to mention that things have gone off the rails.
Dependability is more valuable on an engineering team than unreliable excellence. Why? Because engineering projects at companies are part of a large dependency graph. Before engineering comes research, design, and planning. After comes testing, marketing, feedback, and more research. Some engineering projects block others. Some engineering projects are so critical that the whole company’s continued existence depends on them. An engineer who can ship 2x the number of projects, but half of them drop or are wildly delayed, is nearly useless in this context. They’ll be assigned only the lowest stakes works streams, and even then someone with higher trust will quietly need to pin their attention on the person. This wastes resources and limits the importance of projects the team has capacity to take on.
My advice: Focus on being a dependable engineer. Build and maintain your streak of reliability at all costs. Gently increase your output and difficulty, but all while holding rock solid on your dependability. That’s what is required if you aspire to become more senior, and that’s what your team needs of you.
