How I decide what to work on at large tech companies

One of the most important career skills in tech is learning to recognize what work actually matters. Many engineers go through their careers without really making that decision. They might speak up for a particular issue in sprint planning now and then, but they don’t maintain a mental list of the most important work going on in their team. It’s easy to punt that decision to your manager. After all, it’s not really your job to decide what projects are important—your job is to execute on projects and speak up for the technical side of things.

This is a big mistake! Most prioritized work is low-priority. At tech companies, the job isn’t like assembly-line work where every hour is as important as any other¹. It’s more like being a firefighter: long periods of pretty chill work punctuated by short intense periods where it’s important to get it right.

Why important work is rare

The job’s like that because tech companies can only focus on one or two things at a time. “Focus” means “the CEO is actively following up on this,” and a single person can only follow up on a small number of projects. Think of it as a spotlight moving over the company. When the spotlight is on one of your team’s projects, you had better be willing to drop less critical work and be fully engaged on that project. But the spotlight can only shine on one thing at once—eventually, it’ll move on.

Engineers who have a good sense of what work is important will recognize the early signs of this process and make sure they’re positioned to jump in. Engineers who don’t will be knee-deep in other work when the spotlight hits, and thus won’t be able to immediately move to the high-priority project. This is bad:

• For the engineer, because they lose out on the chance to do work that’s visible at the highest levels of the company.
• For the team, because it means the team has fewer resources to spend on the important project.
• For the company, because it won’t be able to execute as well on the project it’s focused on.

Working on the wrong thing

In the worst case, engineers won’t realize important work is going on and will visibly be doing other things during an all-hands-on-deck situation. For instance, they’ll post on Slack with a question or an update about some unrelated task. This is much worse than doing nothing. Managers really hate it, because it advertises to everyone watching that they’ve failed to focus their team. It’s just a really bad look.

Skip-level managers and above pay attention to which engineers were working (or at least appeared to be working) at times when the spotlight is on a particular team. But they also pay attention to engineers who make obvious mistakes during that time, or engineers who seem to be doing entirely different work. You can spend a year steadily building a reputation and lose it all in a week by looking useless. Or, more optimistically, you can make up for a slow year by absolutely killing it during the right week².

When the spotlight isn’t on you

During the times when you aren’t on a high-visibility project, I recommend carving out your own lab days or 20% time. (Maybe start with 10% time and work your way up.) This is a great way to rack up quick, bullet-point wins that can go on a promo packet or a resume. But it’s also a way to practice putting some skin in the game. If you spend an afternoon on one of your own goals, and it doesn’t provide value, that wasted time is on you. It’s as if you spent the afternoon playing video games. Once you realize that, it forces you to become more agentic, which has all kinds of benefits for your career.

How can a project not provide value? For instance:

• Low-value refactors: unnoticed by engineers, only satisfying your sense of neatness.
• Feature demos that are never going to go anywhere (e.g. because it’s not aligned with company strategy).
• Bugfixes that introduce new bugs, so they’re net-even in terms of effort.
• Performance improvements on endpoints that don’t care about performance (admin panels, low-frequency APIs).

These are examples of the kind of projects that don’t provide value. But the reason a project doesn’t provide value is that it doesn’t (a) build you credit with managers, or (b) build you credit with your fellow engineers.

The value of lab days

One of the most useful things I ever did as a junior engineer was participate in Zendesk’s weekly “lab days.” This was our version of Google’s “20% time” program—the idea was you’d spend one day a week working on something of your choice. The only rule was it had to be at least vaguely work-related: a demo of a new feature, or a piece of code cleanup that wasn’t part of the sprint, and so on.

I don’t remember what I shipped as part of my lab days. It was probably a series of minor performance improvements, since that’s what I was excited about at the time. But the real value was in regularly practicing the skill of choosing what I worked on. And it is a skill: you start out very bad at it. It takes time to learn which tasks will have a solid impact and which won’t.

Summary

• Choosing what to work on is a skill that most engineers don’t practice
• Most prioritized work is actually low-priority, so the real impact comes from knowing when and where to focus
• Tech companies operate on a “spotlight” model where leadership can only focus on one or two things at a time
• When the spotlight is on your team, you need to be ready because high-impact work happens in short, critical periods
• Working on the wrong thing at the wrong time is worse than doing nothing because it signals a lack of awareness and can damage your reputation
• When the spotlight isn’t on you, creating your own opportunities helps you stay engaged and build credibility
• Not all side projects provide value. Good projects either build credit with managers or build credit with fellow engineers