Over the course of my career, I’ve had many jobs which implies that I’ve also left many jobs. Leaving a job can be awkward and emotionally draining, but, depending on the circumstances, also liberating and life-improving.

In this post, I want to provide some guidance on why, how, and when to leave a job based on my experiences so far.

Why consider leaving?

There are many reasons for leaving a software engineering job, some of them better than others. I’ve found that the main motivations for voluntary attrition can be roughly divided into three buckets, described in more details below.

The company

The strongest reason for leaving a job is that you’ve simply lost faith in the company. It could be that the company isn’t doing well financially, has weak leadership, is engaged in behavior that you consider horribly unethical, or has had some kind of downward cultural shift since you joined.

Company issues could also be more benign. The company might be too big and bureaucratic, its products or technology might not be as interesting as they once were, or it might not have a geographic presence in a region you want to move to.

Company-level concerns are really hard to get around because, unless you’re in upper management, they’re outside the control of you, your peers, and your direct manager. Also, switching to a different part of the company won’t really address them.

The team

Another reason for leaving is that there’s something wrong with your team. It might be an ineffective manager, coworkers that you don’t get along with, boring projects, or poor work/life balance.

These can be just as demoralizing as company-level issues (and sometimes even worse), but unlike the latter they’re typically addressable by switching teams. In some cases, it might not be possible to switch teams or other teams might be just as bad, in which case leaving is a reasonable choice.

The role

You may like your company and team, but be really unhappy about something specific to your situation or role. The most common issue here is pay, but other things that fall into this bucket include issues with leveling/promotions, lack of recognition, or a realization that you don’t enjoy certain aspects of your day-to-day work.

These issues are theoretically resolvable, but often require some uncomfortable discussions and negotiations within your management chain, without any guarantees of success. Switching teams can also help sometimes, although if your issues are around money or career advancement, moving laterally could “reset” your accomplishments and put you on the same footing as a new hire.

Alternatives to leaving

Leaving a job is a big step, and the process of finding a new one can be extremely stressful and time consuming. Before resigning or even starting the process of going back on the market, you should carefully consider any alternatives that would help your situation but allow you to stay at the same place.

Switch teams

The easiest alternative to leaving is to just switch teams. Most tech companies allow engineers to do this, and with minimal red tape, provided that:

  1. Your performance is satisfactory
  2. You’ve been with your current team for “long enough”; the precise definition of “long enough” varies from company to company, but it’s typically 9-12 months.
  3. You can find another team that has available headcount and is willing to take you

The great thing about switching teams is that it’s much easier and lower-risk than switching companies, but, at the same time, could give your career just as much of a “jolt” as quitting and starting someplace new would. When I transferred from Cluster Management to Public Data at Google, for instance, the new team had completely different customers, leadership, operating procedures, and technology. It took months to get fully up-to-speed (almost as much as a role at a new company would), and kept me interested in staying at Google for several more years.

Switch ladders

A more extreme version of switching teams is to stay at the same company but switch career ladders. The most common moves I’ve seen here are between IC and management or from engineering to product management.

This is a bit higher-risk than switching teams, but if you really want a change and feel confident that a new type of role will make you happier, it might be worth a shot. Note that, depending on your employer’s policies, you may have to do interviews or jump through other bureaucratic hoops before making this kind of switch.

Negotiate improvements

If you’re dealing with issues that are readily adjustable (e.g., your paycheck) and within the control of your direct manager, then it might be possible to negotiate improvements. There are many, many articles and books out there about how to negotiate effectively, so I won’t discuss that here.

I will note, though, that in my personal experience, I’ve had less than great luck trying to negotiate my way out of unhappy job situations. The main reasons have been:

  1. Most companies are extremely rigid around their HR policies; it’s often easier for them to spend $100k+ hiring and training someone new than give a small out-of-band pay increase, provide better office furniture, allow remote work, or do other things that are orders of magnitude cheaper but go against some existing policy.
  2. Just being good at your job is not enough of a negotiating position. To have the best leverage, particularly around financial demands, you need to get multiple offers from similarly-sized companies. This requires a lot of time and effort, and by the time you’ve done this it’s often easier to just quit.

It’s still worth a try, and you may be more successful.

Take a leave of absence

I’ve never done this personally, but several colleagues over the years have. Taking a break isn’t a guarantee that you’ll feel better about your job when you get back, but it can at least give you more time to think about your situation and explore alternatives without the grind of your day-to-day work. Note that extended leaves taken for voluntary reasons require advance permission from your employer, and, even if the leave is completely unpaid, there’s no guarantee of approval.

Giving notice

Once you’ve decided to leave, you need to figure out when and how to tell your employer; typically this notice is given to your manager, who will then forward it on to their manager and HR.


In the US, most software engineers work “at will” which means that you’re not required to give any notice before resigning. Quitting suddenly, though, will probably piss off your colleagues and burn bridges, so the standard courtesy is to give at least two week’s notice even if you’re not contractually obligated to do this.

I typically err on the side of giving even more notice, sometimes as far as six weeks in advance. The main reason for this is that I’m usually interviewing for new jobs while finishing up at my old one, and I don’t want to have to lie to my manager about why I need to take random vacation days in the middle of the week. Also, giving more notice gives the company more time to address any grievances you have and (maybe) convince you to stay.

Some people say that it’s risky to give more notice than necessary- technically, you could be “walked out” early to prevent you from picking up information or skills that might be useful to a competitor. In practice, though, I’ve never seen this happen at any of my employers- in the end, it’s just easier and less disruptive to let people who want to quit do so voluntarily and on their own schedules.


Once you’ve decided to leave, you should tell your manager in a 1:1, in-person chat. You should be honest about your reasons, but at the same time polite. They may try to convince you to change your mind or chat with other people at the company who might be able to do this. It’s fine to hear people out, but keep in mind that these discussions can be awkward and also a waste of time if you’ve definitively made up your mind.

Once the difficult part is out of the way, it’s time to talk about the logistics of (1) your final date, (2) telling the rest of the team, and (3) transitioning your work to other people. I think it’s best to let your manager dictate the terms on these things (within reason); leaving can cause a lot of disruption, so you don’t want to do anything that will inflame the situation.

Saying goodbye

In the final weeks, it’s important to leave your projects in good shape, have a positive attitude, and generally avoid doing anything that will burn bridges. It’s fine to be honest with coworkers who ask you directly why you’re leaving, but it’s not necessary or beneficial to send long, emotional goodbye messages out to large groups of colleagues.

No matter how unhappy you are, be nice to your soon-to-be-ex-colleagues and get through to the end by thinking about how much better your next job will be.

Final advice

Don’t do anything rash, but ultimately trust your gut. If you’ve exhausted the alternatives and have an offer from another company that would make you happier, then take it.