To stay or leave
As the year turns, you should make a choice.
This is a time of year that people ponder changes.
I don’t like New Year’s resolutions. As I said in my last article, setting a distant, fixed goal (“I’ll read 100 books“, “I’ll cut my food spending in half”) is ironically not a great way to reach that goal. But in my life, I’ve deliberated plenty of changes over this turning of the year. And since many software engineers I talk to are wracked by indecision about whether to stay or leave1, let’s talk about that.
In support of resisting the change
You folks like personal stories, right? Here are some personal stories.
I stayed at Upstart for a long time. For a few years, whenever someone left, I assumed they knew something I didn’t. Why would they leave me, otherwise? But when I asked them why, their reasoning never clicked with me. One of them got a much better offer elsewhere, without interviewing. One of them was excited to join a friend’s company. None of their reasons ever seemed to quite apply to me, so each time, I decided to stay. I don't regret that.
Another example: I’ve had my fair share of difficult managers. Under one of these, I decided to stay and build up the relationship rather that changing managers (or companies). In the long run, this was enormously educational and beneficial for me (and them!).
Some folks I’ve talked to stay in place because they are, for lack of a better word, comfortable. They make enough to support their lifestyle and family, and they get sufficient stimulation from their current position, or from hobbies outside of work.
There’s plenty of material value in staying, even when the grass is greener elsewhere: with tenure comes clout and context.
On the other hand…
In support of making the change
I’ve met plenty of Upstarters who wish they had left the company earlier. I can’t say the same, but I do have to admit that I changed teams pretty frequently. One year, I changed teams twice! I had many different reasons for these moves, but if I had to pick one, it’d be boredom. If I get to pick two, I’ll add this one:
Steven Levitt (of Freakonomics fame) did this little pseudo-scientific study: asking people to flip a coin to decide whether to stay or go, and asking them 6 months later whether they regretted it. On average, the ones who changed were glad the coin had flipped that way. Of course, there’s always a risk of revisionist memory, and those people cannot know what would have happened if they’d stayed.
I mentioned comfort in the previous section as a reason to stay, but for some people, it’s a reason to leave. If your goal2 is to found a company before you hit 30, comfort is a liability, not a feature.
So there’s plenty of value in leaving. New work means new perspectives and new growth, and no learning curve is insurmountable.
You just made a case for both, how is that helpful?
Look, I’m not going to come down hard on one side or another. Simple answers are sus3, and I’d be a hypocrite to unilaterally endorse either path, since I’ve followed both! But maybe we can use the above stories to distill a few useful heuristics:
Are you bored by your current role?
Boredom is generally fixed by making a change. But before making a huge change, investigate smaller changes first. Maybe you can change projects or teams, which is way easier than changing companies! Absolutely talk to your manager about this; it’s a common problem, and they’re well-suited to find small changes so they don’t have to replace you.
What’s the cost of making the change?
Would you have to go back to school for a few years? Would the change burn any bridges?4 Would you need to spend time interviewing at a bunch of companies, or has a clear opportunity arisen?
Is there a specific opportunity in front of you that excites you?
Is some other team working in a domain that you have personal interest in? Is one of your favorite people hiring?
If your answers to these three questions are “yes, low, yes,” make the change. It’ll be fine.
My answers are “maybe, medium, maybe” so what do I do?
Fine, fine. If you insist on an answer, in a vacuum, I have to suggest just making the change. Even if there’s a 50% chance you regret leaving, that regret will come with growth, so the EV of the change is positive.
But if you’re on the fence like this, it’s especially important that you not burn any bridges. Don’t slam the door, don’t point fingers5, and give people as much advance notice as you can. Software engineering is a smaller world than you think.
Just don’t torture yourself about it
Let’s be honest, you’ll be fine either way. If you miss an opportunity to change, another one will come. If you change and regret it, you can change again (and maybe even change back).
So I think the biggest mistake people make is beating themselves up about whichever path they choose. Don’t do that. That’s Bob talking, and he’s just jealous that you can change and he can’t.
Their team, or their company, or their entire career track… take your pick.
I’m not a big fan of setting goals, but other people sure are.
–picious.
Unless it pisses someone off, it’s usually not too hard to return to a previous company or team if you later change your mind. I’ve seen it happen multiple times!
Giving balanced, critical feedback in an exit interview is perfectly fine.
Boredom was never a factor in my case. Almost every time was a fight or flight decision based on the environment.
If I were considering leaving, something in the environment was sub par. E.g. a bad manager, or unimpactful work, or bad culture, etc.
Then I'd consider if I had a shot at "fixing" it, by talking to my manager, or proposing new work, or advocating for a process change, etc.
Being shy here is a bug, beause if there are things bothering you, it might be bothering a lot of folks and that might kill the team if unaddressed.
I'd also consider if attempting the fix was worth the trouble.
When the odds of fixing it were low, or there was not much else in the job that I wanted to try and preserve, I'd jump ship.
If it was in my power to do something about the problem and there were things worth saving there, I'd first try my best to fix it, and only jump if I failed.