Protecting your time from predators in large tech companies

If you’re a competent software engineer at a large tech company, your time is in very high demand. Lots of people will want you to do things¹. You should be very selective about how you handle these requests, and definitely avoid saying yes to everyone.

Helping other people feels good. That’s doubly true when those people are from other parts of the company. It feels like you’re having the kind of cross-org impact that a staff+ engineer ought to be having. But helping other parts of the org is not your main job. Delivering projects is your main job. It’s a common trap to spend your time too generously and neglect the projects that are your actual responsibility. To avoid it, you should identify the people who are trying to claim your time.

Identifying predators

Large tech companies are full of predators: people who want to extract uncompensated work from competent engineers who are generous with their time. Once a predator identifies a good target, they will routinely send work to that person via DMs instead of going through normal channels. “Uncompensated” is a key word here. When your manager asks you to do work, that isn’t predatory, because you’re being paid for it and (hopefully) rewarded for it at review time. When a colleague asks you to do work, that isn’t predatory, because they’re in a position to do you a favor as well. Predators are asking you to do work that gives them a lot of value but doesn’t do anything for you (or is even harmful). Let’s look at some examples.

One common type of predator is a product manager from a different part of the org. I want to be clear that most product managers don’t do this. But in every large org there will be a couple of this type among the product folks, because they’re typically results-oriented people and they’re used to squeezing work out of engineers. Requests from this kind of predator look like this in Slack DMs:

• “I know you don’t technically own this part of the codebase, but could you make a tiny change for me real quick?”
• “I got this (unrelated to your work) technical question from another PM, what’s the answer?”
• “You’re so great at using our data tooling, can you pull some statistics for me when you get a sec?”
• “My team is doing this project that’s related to your part of the codebase, could you make a change here to unblock them?”

This is great for the product manager, because they get unblocked quickly and they don’t have to spend any political capital on getting their work prioritized. It’s bad for the engineer, because they neglect their actual projects and alienate their direct manager (who will resent their engineers being approached directly). That PM from another org won’t be there in your review meetings, and their gratitude will likely be short-lived once you stop providing free work.

There’s another common category of predator: the weak engineer looking for you to do their work for them. Requests from them tend to look like an endless stream of this:

• “I just picked up this ticket and I don’t know where to start”
• “Help, my tests are red [PR link, with no further context]”
• “Can we pair on this ticket I’m working on?” [the pairing is entirely you driving and them watching]

In the extreme case, the weak engineer is doing effectively no work on their own, but drawing on a series of strong engineer friends to complete every task². To each strong engineer, it looks like they’re just helping out a bit. This is a bad deal for the strong engineer, because the weak engineer (a) won’t want to publicize just how much they’re relying on the strong engineer, so won’t share credit, and (b) won’t be able to help the strong engineer out with work later.

To be clear, I’m not talking about a junior engineer who’s learning here - they’ll be able to help you out later when they acquire the relevant skills. I’m talking about an engineer who’s drawing on help from others as an alternative to actually learning the job. You should be very generous with your time to engineers who are learning, and very guarded with it around others.

Not all requests for help are predatory

Not all requests for help are predatory. It’s part of your job to help out engineers on your team, and cross-org impact really does involve helping others sometimes, even if you get nothing in return. Predatory behavior is a consistent pattern of drawing on your time for nothing in return. One warning sign is when the request is itself very low-effort, but is asking you to go to a great deal of trouble. Another way to tell is that requests from predators always come through backchannels (e.g. Slack DMs). Asking in public would (a) make it clear what they’re doing, (b) set you up to at least receive public credit for helping out, and (c) give your manager a chance to step in and protect your time.

I want to doubly emphasize that, by definition, requests from your manager or from anyone in your management chain are not predatory. These people will be involved in your review meetings, and are thus in a position to directly reward you for your work. Helping them out is directly and explicitly your job, and you should prioritize it over everything except the most crucial ships.

Avoiding time-asymmetric requests

One effective rule of thumb to avoid becoming prey is to watch out for asymmetric DoS attacks on your time. Distrust questions that are much easier to ask than to answer. In other words, be suspicious when someone is putting in a small amount of effort to ask a question that would require you to do a lot of work. “I just picked up this ticket and I’m lost” is a very low-effort question that needs you to put in a lot of effort to answer it. “I just picked up this ticket and I’ve tried this (here’s my draft PR) but I don’t like it for these reasons” is a high-effort question.

When someone brings you a low-effort question, give a low-effort answer. That doesn’t mean a wrong answer or a rude answer - just don’t go and do a ton of work. Sometimes that means responding “sorry, I’m not sure off the top of my head”, or “yeah, I think we have data on that somewhere but I can’t remember where”, instead of actually going to look it up. Sometimes it means being vague, like responding “yeah I think you’ll need to update the auth logic in the controller” instead of finding and linking specific files.

This has a few benefits. First, it discourages predators who are looking for an easy target. Second, it immediately frees up your time. Third, it encourages people who you work with to ask higher-effort questions, which is good for everybody.

Summary

• If you’re a strong software engineer, your time will be constantly under attack
• Helping others is not your main job, doing the work is
• Large tech companies are full of predators looking for strong engineers whose time they can use
• Beware product managers from different orgs and weak engineers
• Predators aren’t in a position to reward you (i.e. they’re not in your management chain)
• Don’t let your time be consumed asymmetrically