The job-change decision: stay or leave

At some point everyone faces this question. You feel a weight on your shoulders on the way to work, you check LinkedIn notifications more often than you used to, or you actually read that recruiter message instead of deleting it. Noticing that feeling is one thing; figuring out what it actually means is another.

Over the years I’ve seen that this decision is usually made at the wrong moment, with the wrong information. Either out of anger (“I just had a blow-up with my manager — I’m out”) or through passive drift (“There’s no path forward for me here anyway, so what does it matter”). Neither extreme leads to a sound decision.

Accepting that staying is also an active choice

The most common mistake: not treating “not leaving” as a decision at all. While you’re telling yourself “I haven’t decided yet,” you have already decided — to stay. And that decision deserves a reason too.

If you’re staying, make sure it’s for an active reason that moves you forward: something left to learn, a critical project coming up, a growth opportunity opening up on the team. Staying with intention protects you from burnout. Staying out of fear — “I probably can’t find anything better” — ultimately damages both you and the company.

Legitimate signals to leave

Not every bout of unhappiness is a “go” signal. Sometimes a project ends, sometimes the team reorganizes, sometimes you’re just having a bad week. To distinguish those moments from a genuine signal to leave, I ask myself a few questions:

Has learning stopped? Where have I grown technically in the past six months? If the answer is “nowhere” and the next six months don’t look any different, that’s a serious signal. For a developer, stagnation is silent regression.

Is there a values mismatch? Do I generally find the company’s decisions reasonable — how people are treated, where the product is headed, the technical culture? These answers don’t change fundamentally over time; if the misalignment is structural, you can’t dress it up and learn to live with it.

Have I hit a growth ceiling? Is the next step even possible? Is there someone in the organization who will see me as more capable, and give me the corresponding responsibility and recognition? Counting down under a ceiling without realizing it’s there is exhausting.

If the answer to any one of these three questions is consistently and clearly “no,” that’s something different from vague, gut-level restlessness.

Recognizing temporary frustration

On the other hand, some periods are just hard. An intense pre-launch sprint, a performance review that went badly, a colleague you worked closely with leaving the team — these are temporary weights. Decisions made during these periods often lead to regret.

It helps to ask: “Did this problem exist six months ago? Will it still exist six months from now?” If the answer is no, it’s worth waiting.

Evaluating a new opportunity beyond the salary

When an offer arrives, or when you’re actively looking, it’s easy to fixate on the number. Salary matters — I’m not dismissing that — but making it the sole determining factor is dangerous.

I give equal weight to the following:

The team. Who are the people I’ll be working with day to day? What’s the technical culture like? It’s possible to get answers to these questions during the interview process: how do they communicate with each other, are they open to technical debate, can they find the balance between “testing you” and “getting to know you”?

The problem space. Does the problem I’ll be working on actually motivate me? Is this an area I can work in with genuine enthusiasm for at least the first six months? Enthusiasm doesn’t last forever, but it should at least exist at the start.

The direct manager. Can this person contribute to my growth? “Knows their stuff and won’t block me” is the minimum bar; the ideal is someone I can actually learn something from. Manager changes are difficult and infrequent; a bad pick affects you for a long time.

Technical debt and decision-making autonomy. How much technical say will I have in the project? Am I following along in a fully locked-in stack, or is there a genuine opportunity to shape things?

The cost of changing too often — and never changing at all

Both extremes carry a price. Switching too frequently — every year and a half or so — leaves question marks in your portfolio and leads to skimming from surface to surface without ever reaching real depth anywhere. On top of that, it keeps you chronically at square one in areas that require accumulated experience.

Never switching carries different risks: a perspective shaped entirely by one company’s culture, habits, and constraints. Losing awareness of what’s happening outside. And if that growth ceiling really is low, spending years in a comfort zone that isn’t actually producing returns.

As a general framework: if a role has offered a few years of meaningful learning, growth, and contribution, that’s healthy. What you need in order to leave isn’t “a bad-enough reason to go” — it’s the feeling of “I’m moving somewhere better.”

Sitting patiently with the decision

Don’t rush to answer this question. Both “I need to leave immediately” and “I should definitely stay” can be wrong in the first week. Give yourself a few weeks: are these legitimate signals, or is this a temporary low point?

And ultimately, when you do make the decision — in either direction — make it on your own terms. Not based on someone else’s expectations, and not in response to an algorithmic nudge on LinkedIn.