I used HEY for a week, but I’m going back to Gmail

I’ve been trying alternatives to Google services lately. No offense to Google. I just used their services uncritically for years. Now I want to evaluate them against their competitors. For example, I now use DuckDuckGo instead of Google.

Basecamp released HEY recently. It is a privacy-focused email client that aims to give power back to the user. This sounded like something that I might appreciate. Every Gmail account I’ve owned uses a similar combination of features. Priority inbox, some specific settings that must be checked, a bunch of filters, etc. It’s always the result of iteration and resignation. It never feels quite right. It’s easy for me to believe that an email client could provide me a “wow” experience by encoding my workflow into the UI, and providing an “I’ve never known it before, but I’ve always wanted that!” moment.

I got a launch invite and decided to try it for a week.

Let’s cut to the chase: HEY is a good email client, but it’s not a good fit for my relationship with email. I’m not going to pay for it. But this post isn’t a hit piece. Negativity is cheap and lazy. I’m going to explain the value that HEY provides. I will also explain why it wasn’t a good fit for me.

How I evaluated HEY

I forwarded my personal Gmail into my hey.com account for one week. I got ~120 emails from ~80 senders. I only sent a handful of emails. This matches my personal email load for a typical week.

I kept a running Google Doc with notes. I especially wanted to split my negative notes into a few piles: bugs, dislikes, and mismatches.

I want to focus on mismatches in this post. When did HEY make me feel uncertain or afraid? When was I fighting it?

I’m not going to mention bugs. Do you really want to hear about a problem with using keyboard shortcuts to scroll through email? They probably fixed it before I published this post.

I’m not going to tell you about nitpicky choices that I didn’t like. This post would become a monument to my own change aversion. “The information density is too low! I can only see 9 emails on my laptop!” Jake. Chill. You’ll get used to it.

Anyways, I used HEY on a variety of platforms. I used the iOS client on my iPhone X. On desktop, I accessed it through Firefox on my 15″ Macbook Pro and my Windows gaming machine.

A picture of me in a pumpkin mask.
Thanks to coronavirus, I had two modes this week: feeling unsafe outside and testing HEY inside. I wore my mask for both.

Privacy-first

I like HEY’s privacy stance. HEY explicitly blocks pixel trackers and loads images through a proxy. It will also “name and shame” companies that send emails with trackers by putting a special binoculars icon over the email.

An example showing a pixel tracker notification from Etsy
An example showing a pixel tracker notification

Some digital marketers don’t like this. Mailing list health is an important metric. If they can’t track open rates, then they can’t know how people are “progressing through the funnel” of reading their emails.

Fine by me. It’s hard to imagine receiving any benefit from telling a remote server, “psst, I opened your email.” I like that people can opt-out of ads with ad blockers. I also like that HEY focuses on opting-out of tracking pixels.

I didn’t care about the “name and shame” part of their pixel tracking. I’d be happy if they just had a counter saying “We stopped 531 tracking pixels this month.” I’m not interested in learning who sent an email with trackers. I just like that the filtering works.

The Screener

HEY requires you to “screen in” every email recipient. When someone sends you an email for the first time, HEY shows a button asking you to “screen them in.” You will receive all future emails from them if you say “yes.” You will never get their email if you say “no.”

Do you receive a lot of unsolicited email? Promotional email you never read? Recruiter spam? Then you should seriously consider using HEY. Imagine saying “no thank you” to a spammy recruiter and never thinking about their emails again. Imagine the promotional emails never grabbing your attention. Imagine opening your email every day and only seeing the emails you want to see. That seems to be HEY’s vision, and I like it.

I interacted with the Screener a lot. I received email from ~80 different senders this week. I screened five of them out.

I don’t receive much unsolicited email. I aggressively unsubscribe from promotional mailers. I turn off email notifications that I don’t want. I sometimes delete services if I get too much email as a result of being a member. As a sidebar, deleting my LinkedIn account was a huge email quality-of-life improvement. The constant parade of recruiters dropped to manageable levels. You should consider it.

I spent lots of time considering some of the Screener decisions. I used to have a Netlify project that I have since deleted. I don’t need to receive email from them now. Maybe I should say “no” to a promotional email that they sent me. But what if I want to use Netlify in the future? I liked Netlify. I might use it again. Would my “no” still apply? I would be missing email that I need to receive. What if I lose my job in the recession and Netlify contacted me about a job opportunity? Would it be screened out? I had this kind of debate repeatedly throughout the week. Who is a sender? Is it a single email address? Is it a company? Is it an individual who could be represented by multiple email addresses? What about catch-all addresses like noreply? When can I safely reject email? I only felt safe using the Screener in a few narrow cases. In cases like Netlify, I screened them in and unsubscribed from the mailing list.

I’d like to make two caveats to this section. First: it seems that Gmail does not forward spam to HEY. I don’t know how good HEY’s spam filtering is and I don’t know how important the Screener would be in relation to it. Second: I only used HEY for a week. The Screener was a constant presence in the beginning. It appeared less as the week went on. I imagine that it wouldn’t appear much next week.

The Imbox, the Feed, and Paper Trail

When you screen an email into HEY, you can choose one of three categorizations.

The primary location is the Imbox. This is the IMportant BOX. It’s an intentional spelling, and is designed as an inversion of an email inbox. The logic goes like this: Other people get to decide when stuff appears in your inbox. You need to intervene to stop it. On the other hand, something only appears in your IMbox when you declare it IMportant enough. This means that you have reclaimed power over the email that you receive.

This is also why HEY provides The Feed and Paper Trail. These represent common email types that you may not need to see right away. This is designed to further improve the Imbox experience by moving these emails out of sight until you want to see them.

The Feed is “The place for newsletters, marketing emails, or anything you want to casually browse.” I put a word-of-the-day email, some Google Alerts, and some newsletters into The Feed. Instead of acting like an email inbox, it is designed to be a content reader. You can periodically skim this content. But it’s not front-and-center in your Imbox.

Paper Trail is “The place for receipts, confirmations, and other transactional emails you receive.” I put automated notifications into here: online order confirmations, credit card purchase notifications, Twitch’s “this streamer is now online” notifications, etc.

After using the categorization for a week, it was clear that I struggled with both of them. I receive a daily newsletter with lengthy emails (Money Stuff by Matt Levine). It’s too big to read all at once during my workday. In practice, I sneak 5 minutes here, 10 minutes there. When it’s in The Feed, this means that it was not an email. Instead it’s a card that is slowly being pushed down by other things in The Feed. The later in the day I started reading it, the harder it becomes to complete it 5 minutes at a time. Maybe I’d move this specific newsletter out of The Feed. There’s not much left at this point. I’d have to keep polling to find when the two or three remaining things ended up in The Feed. Everything might as well be in the Imbox.

I also regretted putting many of my emails into Paper Trail. When I buy something, I want to see the purchase receipt Right Now. I also receive credit card alerts for every purchase I make. This helps me identify recurring purchases that I no longer need. When these are in my inbox, I can read and clear the notification immediately. When things are in Paper Trail, they don’t seem to have “Unread” markers. You need to scrutinize timestamps and dates to figure out what might be new. If my Amazon order ships, I want to say “Cool” and then delete the notification. I definitely want to see it.

I fought against this workflow all week. HEY does a good job of explaining its categorization system. But I struggled to live in it. I really just wanted everything to appear in the Imbox. This is the same reason that I stopped using the “Multiple Inbox” feature in Gmail: I’d rather stop unwanted emails at their source, instead of moving it into a separate low-frequency box.

To be clear, this is a good system that is a mismatch with my relationship with my emails. I don’t “casually browse” my newsletters, and I want to read all of my transaction receipts while my brain is still thinking about the purchase I just made.

Other advanced features

There are other advanced features that I didn’t use, or used lightly.

Search worked well. I looked for a few things. I found what I was looking for.

HEY has a pair of features called “Reply Later” and “Reply Focus Mode.” This allows you to put off sending replies to emails. Later, you can enter a focused mode that allows you to reply to these specific emails without any UI distractions. I forwarded myself a few emails to put into here when I was experimenting with HEY, but I didn’t end up using the mode with any real seriousness. I don’t receive a ton of email in my personal account, so I don’t run into this problem much.

You can “Set aside” an email if you need to reference it. I can imagine needing this at work. If someone sent me a lengthy meeting summary that I will convert into calendar invites and bug tickets, I can imagine using this feature. I can’t imagine ever using it in my personal account.

If I could change one thing about Hey

You might expect that I’d want to change something about its workflow. After all, the workflow didn’t work for me. But it’s someone else’s workflow. They enjoy it. I’m not going to mess with someone else’s workflow.

I would invert how the tutorial works. I experienced the tutorial as a three stage process:

  • A guided tutorial of UI elements.
  • A series of emails explaining the UI features.
  • A Screener help card that lasted until I categorized 15 emails.

I experienced this as a breadth-first iteration across the UI. It started broad, and then explained all of the deep features. “This is Hey! We have a Screener! And an IMbox! And Paper Trail! And a Feed! And Reply Later! Here’s the Hey menu that shows all of them!” 

This was stressful in practice. It felt like I was expected to memorize all of the definitions before I proceeded. But then I went back to my Imbox and I didn’t see anything that had been introduced. I realized that it’s all hidden behind a menu. HEY did tell me about this menu. But it told me quite a lot in a 5 minute span, so I didn’t remember.

I came back the next day. I didn’t see any of the other inbox types. Where did all of it go? Oh right! It’s all hidden behind a menu. On the plus side, HEY sends you some of the tutorials as emails. This gave me an easy-to-find reference. They definitely helped. I kept revisiting them over the first few days.

It didn’t need to feel this stressful. HEY’s home screen is an intuitive email inbox. I could read and write emails immediately. I could use the default email functionality without a tutorial. It felt like they wanted me to immediately be a power user, without ever being just a user. Starting out as a power user is a lot of work for my first half hour of using a new product.

I wish that Hey’s tutorial was more spread out and depth-first. I spent most of my week screening emails. I did that more than anything else. So I wish that it focused heavily on the Screener in the beginning, and then introduced the Feed and Paper Trail when I moved emails into it. Later, it could describe the more advanced features as emails enter your Imbox. I understand the pressure to differentiate yourself and prove that you’re worth $100 early in the user’s journey. But the education process didn’t feel good to experience.

The Verdict

HEY is a fast and easy-to-use email client. I think it’s going to have a lot of users and will be fairly successful. It gives me hope that there will be an email client that I would pay for someday.

There are a few situations where I would recommend HEY:

  • Someone reads the HEY features and says “oh hell yes” because this is how they view email.
  • Someone receives lots of unsolicited email that they don’t want to read.
  • Someone is really into multiple inboxes and wants to try a Gmail alternative.
  • Someone needs a structured workflow to manage an out-of-control email inbox. They lose emails under the pile of stuff they received.

After years of heavily curating my email inbox, I believe that I’ve prevented myself from benefiting from these workflows. I found myself pushing back against the multiple inboxes feature. I can’t imagine myself using the “Reply later” feature. All I’m left with is the Screener and the Imbox.

I’m only going to permanently switch away from Gmail once. I won’t be switching to the 2020 version of HEY. I hope that they continue to evolve the email client in a thoughtful way. I can imagine myself switching to a future iteration of HEY based on its privacy stance and its speed.

Finish something every day

When you write code in an engineering organization, you will do the following:

  • Type the code out.
  • Test some of it. Hell, maybe you’ll test all of it.
  • Get someone to review the code.
  • Push it to source control.

These items aren’t discrete or ordered. Test-driven development and pair programming are practices that reorder or merge these items. But these should happen for most changes.

Sometimes, you’re given a large task. You have a question at this point: should I break it up? Should I write the whole thing at once? In my experience, the best tradeoff is to finish something every day, even if it’s small. Write it. Test it. Send it for review.

This introduces a lot of tradeoffs. It’s not always possible. It makes some assumptions about your work environment. We will discuss all of these below.

Benefits

Small changes are better for you

Let’s say that you’re a full stack developer at a web shop. You are assigned a new task: add a new form to collect and store some data, and then display it on another part of the site. The designer whipped up mocks. The product manager wrote out the expected behavior. Now it’s your turn.

You see all of your tasks: Modify a form to collect the data. Include it on the request to the server. Write it into the ORM. Modify the database to store it. Think about the default values and whether we can backfill the data from another location. Read the data from the new location. Render it into the view.

There are a few obvious ways to approach the code:

  • Write all of it at once.
  • Write the database code, write the write path, write the read path.

There’s a less obvious way to approach the code:

  • Write the database code, write the read path (with stubbed data), and write the save path.

There may be other alternatives that depend on the details of your project. But look at what happened: The project is now decomposed into smaller tasks. Even better, we see that the ordering of two of the tasks doesn’t matter. The data layer code blocks everything else. But the other two tasks are independent of each other. You can pick the most convenient task ordering. They could even be done at the same time. This is the first insight of decomposing tasks: some work becomes parallelizable.

Parallelization is where the magic happens. This means that you’ve converted a one-developer project into a two-developer project. This is a great way to grow as an engineer. It lets you practice for project lead or tech lead positions. This also helps you practice for artificial deadline pressure. In an “emergency,” you could make the following proposal to your team: “we can get this out faster if we add a second engineer to this. I can add the model code today. Someone can work on the view tomorrow while I work on the save path.”

It’s also good to practice to go through a full “write, test, review, deploy” cycle frequently. Practice makes perfect. You will become more capable as you push more and more code. Your “small” changes will become larger and larger. It also becomes insurance against seniority. As you get more responsibilities, you will probably suffer from the Swiss cheese calendars that plague many senior employees. It’ll be your job to help people and maintain relationships around the company. People often need help at awkward times on your calendar. If you are in the habit of producing small changes, it’s a little easier to write code. You can still finish something if you have two hours between meetings.

Interestingly, you will discover failure cases as you parallelize work. These failure cases aren’t always obvious. What could go wrong? Some tasks are just too small. Every “write, test, review, deploy” cycle has overhead. Sometimes the overhead is huge compared to the size of the change. You will also notice that saturating a project with the maximum number of engineers doesn’t work as well as it sounds. If someone’s schedule slips, other engineers will be blocked. This is okay in the occasional “emergencies” where shipping a feature ASAP is the most important thing in the world. But you burn intangible resources (goodwill, happiness, team cohesion) by perpetually oversubscribing projects. You will learn to find a sustainable headcount for a project.

There are selfish reasons to ship all the time. Shipping is a form of advertisement. People see that you’re constantly “done” with something because you’re always asking for a review. But this is a double-edged sword. You’re always going to be asking for code reviews. The reviews should be worth the time of the reviewer. Make them large enough to be interesting. If you’re distracting them with adding a single line, you’re doing the team a disservice. This is why I’ve found “a day of work” to be a good tradeoff.

Better for the codebase

I’m going to tell you a horror story. Remember the above example: adding a UI feature to a web app? I’m going to work on that change. And I’m going to do the whole thing in a single pull request. I swoop my cape over my face and disappear into my evil lair for over a week.

I send you the code review out of nowhere. You look at it. Thousands of lines added across a few dozen files: tests, database configurations, view templates. This is going to take forever to review. You skim the files. You eventually get to the database file. You see that something is wrong: I should have added another table for the new data. Instead, I wedged it into an existing record. And this change was foundational. The write path depends on this mistake. The read path depends on this mistake. The UI on either side depends on this. The tests assert this. Everything depends on this mistake. Fixing this is expensive. It’s closer to a rewrite than a refactoring.

But we’re in the “website economic model” of development. Our sprint process puts downward pressure on how much time this task should take. I shipped a functional version of the project. It’s now your job to argue that we should throw away a working version in favor of a different working version.

This puts you in a difficult spot. The team estimated this task would be completed in under 1 sprint. But now we’re more than halfway to the deadline, and the change is wrong. Fixing it will take it past the end of the sprint. I’m incentivized to push back against your feedback. I may not. But let’s remember: this is a horror story. I’m going to push back. Bringing this up will also invite discussions with product or management stakeholders to negotiate whether there’s a cheaper fix that avoids a rewrite.

Furthermore, it took you forever to review the entire change. You need to do the entire review again a second time after my rewrite. And maybe a third time if another round of revisions are necessary. That could up to hours of reviewing that you’re not dedicating to your own work.

All of this leaves you with two bad options: rubber stamping a bad change (with some perfunctory “I was here” feedback to show that you reviewed it), or reducing your own velocity and your team’s velocity to argue for a gut renovation because of less-tangible long-term improvements.

Ok, let’s end the horror story. What if I had split my task into day-long chunks? My first task would be to write the data layer. So I’d write the database changes and any ORM changes. I’d send them to you for review. You’d look at my changes and say, “Hey, let’s move these fields into a separate table instead of wedging this into the HugeTable. We used to follow that pattern, but we’ve been regretting it lately for $these_reasons.” And it’s totally cool – I don’t push back on this. I take the few hours to make a change, you approve the changes, and I move on.

What was different? I incorporated you earlier into the process. You weren’t sacrificing anybody’s time or velocity. You made me better at my job by giving me feedback early. The codebase turned out better. Nobody’s feelings were hurt. This means that I improved the entire team’s engineering outcome by splitting my changes into small chunks. It was easy to review. It wasn’t difficult for me to fix my mistakes.

Why wouldn’t I split my changes into smaller chunks?

When does shipping every day work? When does it fail?

“Finish something every day” makes a lot of assumptions.

There is an obvious assumption: something worthwhile can be finished in less than a day. This isn’t always true. I’ve heard of legacy enterprise environments where the test suite takes days to run. I’ve also worked in mobile robotics environments where “write, compile, test” cycles took 30 minutes. In those situations, it can be impossible to finish something every day. There is a different optimal cadence that balances the enormous overhead with parallelization.

“Finish something every day” also assumes that the work can be decomposed. Some tasks are inherently large. Designing a large software system is a potentially unbounded problem. Fixing a performance regression can involve lots of experimentation and redesigning, and is unlikely to take only one day. Don’t kill yourself trying to finish these in a day. But it can be interesting to ask yourself, “can I do something quickly each morning and spend the rest of the day working on the design?”

Another assumption is that your teammates review code quickly. Quick reviews are essential. This system is painful when your code reviews languish. Changes start depending on each other. Fixes have to be rebased across all of them. Yes, the tools support it. But managing 5 dependent pull requests is hard. Fixes in the first pull request need to be merged into all the others. If your teammates review them out of order, fixing all of them becomes a nightmare.

If I may be so bold: if you’re getting slow code reviews, you should bring it up with your team. Do you do retrospectives? Bring it up there. Otherwise, find a way to get buy-in from your team’s leaders. You should explain the benefits that they will receive from fast code reviews: “Fast code reviews make it feasible to make smaller changes, because our work doesn’t pile up. Our implementation velocity improves because we’re submitting changes faster. We all know that smaller changes are easier to review. It’ll lead to better engineering outcomes because we’ll provide feedback earlier in the process.” Whatever you think people care about. Ask your team to agree on a short SLA, like half a day.

You can model the behavior you want. You should review others’ code at the SLA that you want. If you want your code reviewed within a couple of hours, review people’s code within a couple of hours. This works well if you can provide good feedback. If you constantly find bugs in their code, and offer improvements that they view as improvements, they’ll welcome your reviews and perspective as critical for the team’s success. If you nitpick their coding style and never find substantial problems, don’t bother. The goal is to add value. When you’re viewed as critical for the team’s success, then it’s easier to argue that “we will all be more successful if we review code quicker.”

I take this to an extreme. When I get a code review, I drop everything and review it. My job as a staff engineer is to move the organization forward. So I do everything possible to unblock others. If this doesn’t work for you, find a sustainable heuristic. “Before I start something, I look to see if anyone has a pending code review that I can help with.” Find a way to provide helpful code reviews quickly.

Finish something every day

Try to finish something every day. You will get better at making small changes, and your definition of “small” will keep getting bigger. You will get better at decomposing tasks. This is the first step towards creating parallelizable projects. Additionally, you will get exposure for continually being “done.”

It helps your reviewers. Smaller tasks are much easier to review than larger tasks. They won’t have to give large reviews. They also won’t have to feel bad about asking for a complete rewrite.

It will also help the codebase. If reviewers can give feedback early, they can help you avoid problems before you’ve written too much code to turn back.

In practice, “finish something every day” really means “find the smallest amount of work that makes sense compared to the per-change overhead.” In many environments, this can be “every day,” but it won’t be universal.

Please consider donating to Black Girls Code. When I was growing up,
I had access to high school classes about programming and a computer
in my bedroom which allowed me to hone these skills. I'd like
everyone to have this kind of access to opportunities.

https://www.blackgirlscode.com/

I donated $500, but please consider donating even if it's $5.

The multi-year process of getting promoted to staff software engineer

Note: these are my thoughts, and not the thoughts of my employer.

I wasn’t interested in promotions for most of my career. I had a simple reason: I didn’t want the jobs that promotions would give me. They would have made me unhappy. But then I joined Etsy four years ago. This put me in unfamiliar territory: I wanted to grow my engineering career for the first time. Getting the next promotion would make me a staff software engineer.

I achieved this a year and a half ago. This is the advice that I’d give myself when I started at Etsy four years ago. I tried to make it broadly applicable. I hope that others find it useful. It is targeted towards senior engineers who are looking to reach staff within a few years.

Let’s chat definitions real quick. “Staff software engineer” varies wildly between companies. Sometimes it’s called a “principal engineer,” and other times a “staff” and “principal” are two different levels on the same ladder. But I’m describing the first level that is partially scoped outside of a team. A staff engineer is often an individual contributor on a team. They are also recognized for having broad impact outside of their team. Maybe they’re clutch on business-critical projects. Maybe they wrote and maintain the framework that everyone uses. Maybe they’re good at coordinating the technical work of huge projects. Maybe they do all of that. They’re senior employees who have started to level up other parts of the company.

Understanding the process

First, understand the mechanics of how promotions work. Read any documentation on the evaluation and promotion process.

Let’s imagine a process at a mid-size company.

Employee evaluation

  • Every level has written performance expectations.
  • Employees write a self-evaluation every 6 or 12 months. They compare themselves to their level’s written performance expectations.
  • Managers assess their employees. This produces a rating against the performance expectations. This may contradict the employee’s assessment.
  • There is a company-wide adjustment process. This attempts to correct for the fact that different managers might rate the same employee differently.

Employee promotion

  • A promotion candidate should have two consecutive evaluations showing that they are meeting the next level’s criteria. There may be some flexibility here.
  • The employee or the manager will document the employee’s promotion justification. This is often called a “promotion packet.”
  • The promotion packet follows a template. The company is “trying out a new template that is much shorter than it used to be.” It will still take forever to fill out.
  • The manager collects peer reviews from higher-level employees that are familiar with the candidate’s work.
  • One or more high-level employees read the reviews and packet and make a decision on the promotion.

To some approximation, this is what formalized promotion processes look like at mid-size companies. Most companies aren’t trying to innovate here. I’d be suspicious if they did.

Understand the real promotion process

I had a misconception when I was a new grad. I figured that companies followed their written rules. It turned out that this isn’t true. Companies develop their own conventions and interpretations that might surprise the casual reader. There are also unwritten rules that you’ll learn over time.

What do I mean? Let’s take hockey as an example. The NHL has an official rulebook. You could read it today. The rulebook explains how hockey is supposed to work. Rink size, skates, sticks, face-offs, 20 minute periods, offsides, power plays, overtime, waivers, etc.

You read the rulebook. Armed with your new knowledge, you watch some games. The rulebook prepared you fairly well. But some things confuse you.

Every game has blatant infractions that the refs ignore. A few hooks aren’t penalized. Power forwards ram into goalies and goalies cross-check them back. Hits behind the play. The referees see it all. Yet they don’t call penalties. Even more confusingly, other rules are universally obeyed. The players avoid offsides penalties and the linesmen call them. There was a high-stick, and the offending player looked at the ceiling in frustration and skated to the penalty box without a struggle.

Then you’ll notice other oddities. Sometimes, the refs will make a blatant mistake. A star forward falls over when skating past an opposing player. The refs raise their hand: tripping. The star player’s team has a one-man advantage for 2 minutes. But then the video replay shows that the star player just fell over. Even pros lose their edge sometimes. It shouldn’t have been a penalty. The man advantage is unfair. But then the oddest thing happens. Later, the refs will make a second mistake in the opposite direction. Maybe it wasn’t a “mistake,” but they called a penalty they normally ignore.

What’s going on?

Hockey would suck if referees called every possible penalty. The game would take forever. Nobody would watch it. So the refs “put the whistles away” when games are under control: they avoid stopping play by ignoring minor infractions. Additionally, the officials have their own unspoken rules. Maybe they award make-up calls to correct accidental imbalances. They could make the same game different for every player. In fact, one of the most punitive tools available to a referee is holding just a single player to the letter of every rule. This isn’t unique to hockey.

I could go on and on. But let’s face it: the NHL rulebook doesn’t define all of the rules that govern a hockey game. It’s the NHL’s best effort to write down what hockey should be. In practice, the referees decide what hockey will be on any given day. But what if the rulebook grants the referees discretion? It doesn’t change the argument. Different refs will call the same game differently. The enforced rules still vary from the written rules in ways that can’t be learned from the rulebook.

The actual staff engineering promotion process

What lesson can we draw from hockey? The staff engineering promotion process will differ from the written process in ways that are hard to predict. You should be aware of the differences.

These differences can be discovered. Ask existing staff engineers what surprised them about their promotion. Ask your manager. Ask your manager’s manager. Disgruntled Glassdoor reviews or blog posts might have some perspectives that correct for survivorship bias.

In theory, promotions are awarded based on merit. In practice, nobody has equal context across all departments. The decision will be imprecise. Discussions and decisions rely on the written reviews and personal opinions of the participants. People always describe this part like it’s shrouded in mystery. But in practice it’s just “people trying to decide something,” and will have all of the properties of this type of system.

Sometimes there are secret rules or systems. You should try to discover them. Sometimes the secret rules are mundane, like “HighRankingEmployee thinks that employees should be at their level for three years between each promotion because otherwise how could you have enough of a track record?” Sometimes these rules are secret because the company would get sued if they were written down. If you’ve been in the industry long enough, you’ve heard stories about how someone (usually from an underrepresented group) learned that their salary was dramatically less than their peers. Here’s an example if you need one. The employee handbook doesn’t say “Take advantage of structural discrimination and information asymmetry to save a few bucks.” But that’s what the company does. I don’t have a good guide for finding this out. It’s not like you can just ask at the next all-hands. But making and maintaining lots of work friendships opens you up to hearing this kind of gossip.

So, yeah! Understand the written promotion process. And talk to people to understand the human element of the promotion process.

Being honest with yourself

I joined Etsy as a senior engineer. During an early conversation with my director, Tim, I asked what the staff engineering promotion process is like. Tim turned it around on me. “Why do you want to be a staff engineer?”

I was caught off-guard. I should have admitted the truth: I hadn’t asked about this when I was interviewing and I was curious. Instead I stammered out a half-baked answer. Tim listened and said, “It sounds like you haven’t quite figured out why you want to be a staff engineer. It’s not the right path for everyone. Please understand the answer to this before you spend a lot of people’s time trying to get there.”

Fair.

It took a while to find an answer. I got there eventually. Someone asked me a year later and I answered “I was never super interested in my career before I joined Etsy. And I probably could have joined some other company like Facebook and given 5 years of my life to the Like button. But I joined Etsy because I like the idea of helping small sellers sell their stuff on a global stage and giving them a platform to help pay the bills or be their own boss. Performing at my job means that I’m enacting more of a change that I want to see in the world. Becoming a staff engineer means that I’m starting to make the entire organization more effective at enacting the positive changes that I want to see in the world. It’s important to me to keep leveling this up.”

Don’t memorize the paragraph that I have above. That was my reason. It’s important to find your own reason.

Why? It helps you avoid wasting years on a goal that will make you unhappy. Maybe you’d rather work towards becoming a director because you’d be energized by running a department. Maybe you look at the people above your level and think, “I’d be really unhappy if I had any of their jobs.” Maybe you live and breathe tech and less hands-on coding would make you dissatisfied. Maybe your passion lives outside of work and you need something that pays the bills. There are so many valid career paths. It’d be a shame to spend years reaching for the wrong one.

Getting yourself in position

So you want to be a staff engineer. What next?

First, you need to execute at the level of a staff engineer.

Have a frank conversation with your manager about your performance and career trajectory. I’ve found it useful to just say, “My rough plan is to ‘exceed expectations’ in $cycle and to get promoted in $next_cycle. Does that seem realistic?”

Expect the answer to be “no.” That’s okay! Setting a target and expressing interest helps both of you. Your manager can guide you towards projects that will help you grow. They can find you opportunities. They can give you realistic expectations. They can tell you that you need to work longer before you even ask about it. But they may not do any of these things if you don’t express interest.

The goal of promotion is twofold: meet the performance objectives of the next level, and to demonstrate that you are performing at the level. These are subtly different. You should always find ways to leave breadcrumbs of your accomplishments. This provides evidence that you’re performing. This usually involves leaving a summary. Consider the case where you consulted on another team’s project across a few meetings. You could email out a meeting summary of each meeting and everyone’s contributions. This will provide a record of your accomplishments that might have otherwise been lost.

I want to be clear: the first priority is to be valuable. The second priority is to prove that you added value. Are you hyping up work to make it sound like you’re meeting a competency? Then you’re not meeting that competency and you’re not performing at the staff level yet. Performing at the level is foundational.

Schedule meetings with people who have worked with you for at least 6 months. Bonus if they’re more senior than you. Bonus if they’ve worked at the company for a long time. Bonus if they’re directly involved in the promotion process. Ask them questions like “What’s the difference between me and a staff engineer?” You’re hunting for objections that people might have to your promotion. You’ll notice themes after asking a few people. These are the possible objections that people may raise when you apply for promotion. Work hard to grow past these objections. Be mindful to produce evidence that the objections have been overcome.

Are you known for quickly implementing things? Consider spending an hour a day working on high-impact side projects. These projects should be low-effort and high-reward. These types of projects are easier to find at mid-sized companies. Mid-size companies are large enough to create small problems, but small enough to have trouble allocating resources to fix them. Need an example? Write a testing utility to reduce boilerplate for a common testing situation. People should want the result. Explain it to a few people if you’re not sure. If nobody says some variant of “I wish that someone did that,” consider picking another project. Tell people after you implement it. Send an email or Slack message or whatever telling people about it. Rinse and repeat. You’ll get better at identifying these projects over time.

You might want to change teams to pursue a good opportunity for promotion. There are lots of valid reasons to look for a team change. Maybe the new role will clearly help you grow compared to your current job. Maybe you’ve always wanted to work under the new manager. There’s nothing wrong with changing teams. It’s just business. But don’t change teams solely for a promotion. That’s a recipe for unhappiness. A good fit is way more important. You may need to overperform your current role for years before you are promoted. Find a team where you may be happy for years.

Putting yourself in position is not a solitary process. You will need the feedback, help, and support of everyone around you. You need your manager’s support to produce a good plan and be on the right projects. You need your colleagues’ support to help you identify your blind spots to get yourself promoted. And you need your teammates’ support to work on projects with you (and potentially under you, if your promotion plan involves being a tech lead). Don’t forget this.

Providing the evidence

You’ll be ready when your manager is willing to defend your promotion. At a mid-size company, it’d be difficult to be promoted without your manager’s support. This may not be true in FAANG-sized companies that have realized that processes need exceptions. But a smaller company may not yet have any workarounds.

First, gather all of the evidence that supports your promotion. You can collect this from a variety of places:

  • What have you committed?
  • What pull requests have you commented on?
  • What designs have you written?
  • What designs have you commented on?
  • What meetings were you in?
  • What documentation have you written?
  • Who have you been mentoring?
  • What emails have you sent?
  • Who can vouch for your work? Can they write you a recommendation level?

Understand how the promotion packet is crafted. The manager will do part of it. This could range from “the manager writes a statement in support of the employee” to “the manager summarizes the entire argument for promotion.”

Manager involvement has benefits. Managers are supposed to understand the performance management system. They are well-positioned to craft persuasive arguments within this system. Heavy manager participation also has drawbacks: managers are most overwhelmed during performance management and promotion season. The most overwhelmed may be forced to make hard choices about how to spend their time.

Help your manager before the process starts. Write a document summarizing how you met every competency. Provide links. “I worked on ProjectX and produced these designs: [link, link], and had the following technical accomplishments: [link, link]. I had mentorship relationships with $engineer_x and $engineer_y, and wrote $internal_documentation offering people suggestions on how to effectively mentor engineers.” Err towards oversharing. Make it easy to copy and paste. This means that the writing should be polished.

Don’t overstate your accomplishments. If you worked on a design with someone, say that you “co-designed” it. Don’t make it sound like you implemented entire projects if you were one part of a team. If you’re ready for promotion, you should be able to directly state why your accomplishments met the guidelines.

Managers are familiar with your work. But they’re not living your life. They may not remember all of your accomplishments, especially ones that happened outside of the team. Be sure to produce the summary. Don’t hold back. They can cherry pick what you gave them.

What if your promotion may be borderline? This can happen naturally: the performance process happens at a fixed cadence. Sometimes it doesn’t happen at a perfectly convenient time. Focus on the story of why your accomplishments meet the promotion guidelines. Remember all of those electronic records that you’ve been producing about your accomplishments? Extract and summarize the themes from them. Use the records as proof. Pull things into linkable formats and provide the links. People like stories and they like having reasons for their decisions.

What if you get rejected? Rejections are okay, even if they feel bad. They’re not permanent. They simply mean that you either haven’t persuaded everyone that you’re meeting the guidelines, or there are guidelines that you need to meet. Have the specific objections explained to you. Keep asking until you are given specifics. Vague reasons are difficult to address. Don’t accept the “keep doing what you’re doing” explanation. 6 months later, you probably kept doing what you were doing, but you still won’t get promoted. “Not enough of a track record” isn’t a specific reason. “If you launched your current project, we’d have the evidence we need” is a specific reason. “You met the technical criteria, but your teammates report that you give harsh feedback so we’re worried about putting you in a broader role” is a specific reason.

Work with your manager to develop a plan for showing evidence that you’ve overcome those objections. The evidence is important. It will provide the story about why you’re ready for promotion the next time. “We thought that they hadn’t provided enough mentorship. But in addition to the 1:1s they had been holding with their teammates, they took a few professional coaching sessions on mentorship, they onboarded 2 new engineers, and polished and promoted the team’s onboarding documentation for everyone across the company to use”

In summary

Understand the process: Talk to as many people as possible about your specific company’s promotion process. Learn how it’s supposed to happen. Learn how it actually happens. Understand the human elements that factor into the promotion decision.

Put yourself in position: Learn how to perform at the necessary level. Have frank performance conversations about how you are performing, and how people are perceiving your performance. Do everything that you can to address any objections that people bring up. Leave evidence about your accomplishments.

Provide the evidence: Help your manager when you’re going up for promotion. Provide a summary of how your work meets the promotion threshold. If you get rejected, ask until you receive specifics. Then, work with your manager to craft a plan to overcome these objections.