Senior engineers should make side bets

When you’re a junior, you should work on what you’re given. There are two reasons for this. First, your work needs to be supervised and checked by a more experienced engineer, and if you go and work on random things it makes it hard for that engineer to stay across what you’re doing. Second, the way for a junior to build reputation and get promoted is to crush the task in front of them.

However, senior engineers should not only work on what they’re given. There are also two reasons for this. First, if a senior engineer spends all their time working from a list of tasks (GitHub issues, JIRA tickets, and so on), they’re likely to miss the work that’s actually important. Second, senior engineers should spend 10-20% of their time making side bets.

What is a side bet? It’s a project or task that you think will be valuable to the company, but that isn’t on anyone else’s radar. It could be a new feature, or a performance optimization, or a change that will speed up development - as long as it could provide a concrete benefit¹.

It’s important that the benefit be concrete, because side bets are risky. At best, you risk wasting your time. Work that provides no concrete benefit and that you weren’t asked to do may as well not exist: you could have just as well spent your time with your family, going for a walk, or playing video games. At worst, you risk alienating your management chain and gaining a reputation as an engineer who wastes time on unimportant work.

In fact, many side bets will fail. You’ll build something that nobody uses, or that doesn’t really make things much faster or better. In this case, the less said, the better. You shouldn’t advertise the fact that you spent time doing this. Just write off the time you spent and move on.

So why make side bets? The biggest reason is that successful bets pay for everything. There are few better ways to gain a good reputation than by making a bet that pays off. That’s because of the value over replacement problem: for regular work, even if it has a huge positive impact, some other engineer could have come in and done the same thing. But if a side bet you make has even a minor positive impact, that’s all you. Nobody else would have done that.

When you make a successful side bet, you should tell everyone about it. Write an internal blog post or Slack message, talk to your manager, brag to your colleagues - it won’t already be on their radar, so you’ll need to let people know you did it. This is also a good forcing function to ensure your side bet is actually successful. If you can’t bear the thought of bragging about it, it’s probably because you can’t point to enough concrete benefit.

At any given moment, I try to have one or two side bets going. Sometimes they take a week or two; sometimes they take a few months. As an example, my most recent ones at GitHub (that I can talk about) are building an “open your prompt in the prompt editor” button and integrating AI inference permissions directly into GitHub Actions. The prompt editor button was a bust. Unfortunately, nobody uses it. The Actions integration was successful, though - it’s already seeing real usage and customers we talk to are bringing it up unprompted. You win some, you lose some.

I like side bets because they’re as close as you can get at a large tech company to being judged purely on results. If you’re somehow able to win almost all of your side bets, you could probably spend 90% of your time on them and do very well. If you never win any of your side bets, you probably have poor judgement and should stop trying to do them. I win two or three side bets a year, which I think is pretty good.

Summary

• You should work on what you’re given, but if you’re senior you should be spending 10-20% of your time on work you think is important
• If it succeeds, tell everyone about it
• If it fails, drop it and silently move on to the next thing
• A side bet succeeding means that it produces concrete benefits
• If you keep failing at side bets, it might be time to stop