DEV Community

Cover image for When is it time to leave?
Kyle Stephens
Kyle Stephens

Posted on • Updated on

When is it time to leave?

Now that the new year has arrived, the festivities have been wound up and you’ve started to settle back into the day-to-day work routine, you may find yourself with some nagging doubts about your job.

Maybe it’s simply a case of the January blues? How do you really know when it’s time to call it day and move on?

Over the past five years, I count that I’ve worked with 8 different product teams. These have varied in size and scope, with the smallest consisting of a team of four - 3 designers and 1 developer, working to supply deliverables for an offshore software delivery centre - to the largest, consisting of 16 developers and 8 QAs working with a separate product design department of UX researchers and UI designers.

I’m not a serial job-hopper, however. Much of that time was spent working as a consultant for a single professional services firm. This allowed me to change roles and experience different company cultures without actually changing job. I’ve experienced first hand a number of different working situations - some pleasant, some not-so-pleasant. As an external observer, I’ve also witnessed no fewer than 3 mass exodus, ‘brain-drain’-type events where more than 50% of the team have left within the space of 1 - 2 months.

I’ve reflected on some of these situations in order to share my observations and stimulate your thinking about happiness in the workplace.

Slow-and-Steady Projects

Slow projects

These are projects where the pace of life is steady (some might say ‘dull’), there are no meaty technical challenges to tackle and you find yourself actively trying to find new ways of keeping yourself occupied. The days tend to drag and you find yourself watching the clock quite a lot.

If you enjoy the leisurely pace and have teammates with whom you get along, you could probably comfortably totter along at this pace and enjoy yourself for a while.

However, if you are driven by personal growth and learning through tackling new on-the-job challenges then you will probably find you aren’t enjoying yourself very much in this environment. In this situation, your options might be to arrange a meeting with management and to request extra responsibility or move to another team, if these opportunities exist. You could also pursue some personal projects whether that’s personal learning projects, some form of side hustle or participating in OSS communities.

If you’ve tried all these but still find yourself underwhelmed on the job, it’s probably time to call it day and move on.

Death March Projects

Projects with crazy deadlines

This is the opposite of the previous scenario in terms of the day-to-day pace of work.

I’m sure most developers will be familiar with the following project management joke: “I've set the wedding date. I've not asked her out yet." -How software projects are managed.

The death march project will typically occur when a project manager (if dealing with “the business”) or sales (if dealing with clients), without prior consultation with the engineering team, commit to a project scope and deadlines that are either naive or very ambitious.

These projects can typically throw new challenges, present an opportunity to showcase abilities and enable you to set yourself stretch goals - pushing your limits beyond what you have previously achieved.

However, these types of projects are liable to make developers particularly susceptible to burn-out and can lead to team dysfunction due to pressures under time constraints.

Whether you want to engage in this is really a value call on your part and probably involves a number of variables, e.g. how long you think the project will take and whether you think working at an increased pace for that period of time (or perhaps longer) is sustainable. Other questions you should ask yourself are whether there is scope for advancement after successful completion of the project? Whether the project involves novel challenges or merely the same type of work under increased time pressure?

If you’ve assessed these variables and think it sounds like a worthwhile personal challenge, I encourage you to go for it. You just might be surprised by what you can achieve! If you don’t feel up for the challenge or you feel the requests are unreasonable, it might be time to call it day and move on.

Opinions/Insights Ignored

Opinions Ignored

Steve Jobs once said “it doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.”

Now that’s not to say that we as developers should always get our way with having the latest tools and technologies simply because they look cool or satisfy our urge to experiment and learn. However, when people work in an environment where their skills and specialisations count for little because their data, insights and work are overruled by HiPPOs (the Highest Paid Person’s Opinion), frustration will soon grow and they will eventually leave.

For example, I once witnessed an entire product research team with more than 30 years combined experience evaporate over the space of a month because all their work - UX workshops, customer interviews, prototyping and validation - were repeatedly trodden on by the senior executives who proceeded to overrule the team’s data-driven designs and insights with their own decisions and compromises that were bad for the product and ultimately for the end-user.

Lack of Suitable Processes

Unsuitable Processes

I say “suitable” processes because what applies to one set of circumstances may not apply to another - for instance, a large government project will likely have many sets of checks and balances because the need for security and stability trumps speed. On the other hand, a fledgling startup with a team of 3 or 4 may have little to no processes because things are constantly evolving and changing.

The problem lies where the approach adopted is not appropriate for the particular circumstances. This can be particularly common where a startup has enjoyed success, scaled-up its team and then finds that what worked for it in the past doesn’t necessarily work for it anymore.

Maybe you find yourself in a situation where your team describes its approach as ‘agile’ but in reality this is just a byword for constant fire-fighting? PM are blaming developers for late delivery? QA are hounding developers for bugs? You’re in the middle of a perfect storm of chaos and confusion.

You can judge a workplace by how long it takes to get simple things done. When it’s strangely impossible to get something done that you have easily accomplished before in other environments, then you are in a deeply inefficient workplace.

If you feel like trying to influence change for the better in your team, perhaps you can look at this as an opportunity to expand your leadership skills by becoming the team’s agile coach/advocate. If you feel up for the challenge, some recommended reading on the area includes:

Maybe you have tried this already but are failing to get senior management buy-in - perhaps the dysfunction is across the entire organisation and meaningful change can only come directly from the top. In this case, if you think you can no longer continue with how things are operating on a day-to-day basis, perhaps it’s time to call it day and move on.

Oversold Job / The Real Job Doesn’t Match The Job You Were Hired For

Job doesn't meet your expectations

Were you promised a methodical, agile environment with well-organised sprints, a full suite of tests and adequate documentation only to discover that the reality was quite different? See the point above on processes!

Perhaps you were disheartened to find out that that super-exciting, greenfield development project you were promised never materialised and you instead find yourself bug-fixing for an old legacy system?

If you work for a larger organisation, have heart - these things can sometimes take time. Do, however, make your disappointment be known to management who may help clarify the situation or may make the necessary changes to your situation. I have seen situations where we had newly-hired staff who management had hired without a specific purpose or role in mind and had all but forgotten what their specific skill sets were only for us to discover that they were super needed on our team for our current project!

If, however, nothing changes in spite of reassurances, it might be time to call it a day and move elsewhere.


Are you thinking about moving or have you recently moved job? What prompted the move?


For insights into how engineering teams work, visit Tabspace.io, the peer-review site dedicated to software development, with insights from employees who know best.


If you enjoyed this article, keep in touch!

Latest comments (37)

Collapse
 
robdwaller profile image
Rob Waller

Great post, I've experienced much of the same.

Collapse
 
napoleon039 profile image
Nihar Raote

Wow, an interesting peek into some of the reasons why developers leave a company. I had kind of heard about some of these reasons, but you laid it out in a great way🙂. This shows we should research the company, their culture the best we can. And the part when an interviewer asks us whether we have any questions - that's a really great opportunity to get to know the inner workings of the workplace to know if it's a good fit for us. Granted they could hide the truth or just flat out lie, but I guess it helps to identify early on if what we were hired to do is different from what we get to do on the job.

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
ky1e_s profile image
Kyle Stephens

I really don't think so. You have a very valid reason which you can explain clearly to any prospective employer (as you have just done here). Congrats to your wife and to your family :)

Collapse
 
sebastienkb profile image
Sébastien Kalb

I have a somewhat different experience.

I quit my job last week and doing notice time now. It was a startup, I'm not a founder but I was there since almost the start (4+ years going from 4 people team to 20+).
Being a "veteran dev" had more drawbacks than advantages:

  • Knowing the old code base makes you its support guy by default. New devs aren't bothered to learn it because it would scare them off.
  • Customers know you're knowledgeable of their problems, so they ask you explicitly ("May I talk to X instead? He knows how to fix this").
  • New managers don't know what you accomplished, what you deserve, and where you suffered. All your achievements are reset and you have to proof yourself from scratch in their vision. This was the most tiring considering management changed every year in the past 3 years.
  • You're somewhat irreplaceable in your job and when you consider quitting you get the extra pressure from your teammates to stay, as if the fate of the team depended on it.
  • Management takes veterans for granted because "they have gone through worse anyway", so when you finally quit it's all shock and surprise.

I'm glad I decided to leave but this notice time is awkward.

Collapse
 
ky1e_s profile image
Kyle Stephens

That's an interesting perspective. Thanks for sharing.

I don't think you need to feel any guilt. You've obviously helped the company grow through your contributions. The best thing you can do to leave with your head held high is to probably continue giving it your all during the notice period and ensuring any appropriate handovers are made and documentation is signed off.

Collapse
 
astarael2 profile image
Simon Mills

This is a little too close for comfort... Though it is nice to know it's not just a problem at the company I'm at currently. Things are getting better but everything moves at the speed of corporate. i.e. Glacier pace.

Collapse
 
ky1e_s profile image
Kyle Stephens • Edited

Thanks for reading.

I wouldn't immediately discount all corporates as some are more nimble than others.

I'm sorry the role's not everything you'd hoped it to be. If you find yourself with downtime, maybe you can use it as an opportunity to learn whatever new technologies or approaches you'd been wanting to look at. You could even turn that learning into a career-booster by starting a community of practice in the office around that new thing you're learning?

Collapse
 
tunaxor profile image
Angel Daniel Munoz Gonzalez

Well This indeed tells me stuff I've been wondering when I'm about to leave in other jobs, I'm glad to know I'm not the only one considering these things

Collapse
 
whozzawuzza profile image
'''⌐(ಠ۾ಠ)¬'''

This may have been touched on in other postings on dev.to, I can't recall, but how long should/would you give any of these situations before you swap out, particularly if you haven't been at the company a long time?

For example, I've been in my current role ~7mo, mid-to-senior level full stack JS dev. A month after I started, they fired - without warning - an entire team (20+ people) at a different office, for reasons both valid and otherwise... However, it's made the HiPPOs extremely sensitive to anyone's tech opinion. Both how they handled that situation and how they're behaving now makes me very uneasy. I'm not opposed to learning new things, as most of us are here, but when I'm a JS heavy dev and I'm told "it'd be a good idea to learn .NET" here - to bug fix legacy systems that are 6-8 years old, that seems like a huge red flag as well.

I've had quite a number of recruiters and companies reach out in the last month or so. Will it look bad on my resume, or to future employers, if I've got a stint <1 year on there? I mean, on one hand, current interests don't seem to care, but I'm thinking long term.

Collapse
 
antero_nu profile image
Antero Karki

If you have a valid explanation for why you quit within a year, it shouldn't be a problem and it sounds like you do, "they want me to do .NET but I want to focus on JS which I was hired to do. Turbulence within company etc" Been in a similar situation and have been asked why I want to leave so soon and my reasons were fairly similar to yours. I'd like for that to be the exception though.

Collapse
 
ky1e_s profile image
Kyle Stephens • Edited

That's a tricky one and the answer you get will depend on who you ask.

Some would say that the idea of a 'job for life' is now gone and that no job is ever stable - as evidenced by the fact that an entire team of 20+ people were let go! So, if companies have no loyalty to their employees, maybe there shouldn't be an expectation that the loyalty goes the other way round either? Others may disagree with this view.

I think it's important that you leave for valid reasons however and can justify these at an interview. Any prospective employer would probably be wary of someone who leaves on a whim for trivial reasons.

In any job search, it's a good idea not only to assess the role at hand but also the other potential roles in the organisation - e.g., is there scope for growth, advancement, new learnings, new types of roles, new developments. That way you're more likely to find a company you can enjoy a long tenure with - which is probably preferable to regularly being the 'new guy/gal' anyway, right?

Collapse
 
mrmovl profile image
Tomke Reibisch

Nice and organized writeup. You matched my believes exactly, but my thoughts where never that consize :)
I am about to start a new job, because the old one had problems with Hippos and didn't handle the scaling thing well regarding processes. So many passages I could quote :)

Collapse
 
ky1e_s profile image
Kyle Stephens

Thanks for reading :)

Collapse
 
arvindhmani profile image
Arvindh Mani

On a side note:

"These projects can typically throw new challenges, present an opportunity to showcase abilities..."

Think carefully before you use the words "throw new" in a sentence on a software developer article!

Collapse
 
ky1e_s profile image
Kyle Stephens

;)

Collapse
 
haccker profile image
haccker

gg

Collapse
 
pozda profile image
Ivan Pozderac

Never ending legacy projects maintenance did it for me.

Collapse
 
ky1e_s profile image
Kyle Stephens

Yeah, that'll do it alright. Although, the flip side is that sometimes, the more legacy - the more lucrative! For instance, have you seen how much a contract COBOL developer can command!?

Collapse
 
pozda profile image
Ivan Pozderac

Of course, but i'm talking about not so old legacy code. for example i had to do some projects on node sass which is fine, but for older projects also had to have ruby sass installed. that's not problem either, but also had projects on various typescript versions, no docker, so changing path variables manually was only option. people were writing features for this projects and they needed me to do some bugfixes on my side here and there and sometimes there was gap of few weeks before i got back on project. I ended up installing and configuring some new software almost every time i worked on them, not to mention that i had to juggle 3 - 6 projects daily. you can get irritated pretty quick when half of day is reconfiguring stuff for 15min of actual work.

i would never prefer money over sanity.

Thread Thread
 
ky1e_s profile image
Kyle Stephens

Ah yes, I was only teasing (you should check out what COBOL looks like to see what I mean!)

That is frustrating alright. Sometimes in those situations the people who make the requests don't realise the real cost involve in making the updates - the context switching, environment configuration, focus switching, etc. - I find it sometimes helps to explain to them the real cost in terms of your hours and they may realise these minor 15min updates aren't worth the 2+ hours it takes to make implement them. Either that or they could hold the requests and batch them together so that there is a significant unit of work to be undertaken in one go.

Thread Thread
 
pozda profile image
Ivan Pozderac

i totally agree with you, but when pm lets client micromanage all the things and when everything task is of urgent importance, there's no room for sanity

Collapse
 
dsanchezseco profile image
dsanchezseco

HiPPO's everywhere! And more important, non-tech HiPPO's talking about tech decisions. Worst ever that can happen.

Collapse
 
ky1e_s profile image
Kyle Stephens

It's important to differentiate between 'product' decisions and 'tech' decisions. If it's the latter, there's likely a problem for sure.

Collapse
 
dsanchezseco profile image
dsanchezseco

Sure, the tech must address the business, but do not talk about the different tech solutions as long as they solve the problem, I, a developer, I'm paid to think and know about that

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

I think I've left jobs for all of these reasons.

Don't forget there is also "better opportunity" as a reason to leave. Your current job could be fine, but there's a better one available. A bit of a gamble, but often a good reason.

Being able to a leave a job that doesn't fit (for any reason), is vital to your career.

I find that by the time you start asking yourself the question, "Should I quit?", it's about the right time to do so. Or at least, force the current job to change.

Collapse
 
ky1e_s profile image
Kyle Stephens

A better opportunity is a solid addition.

I think we, as developers, are super privileged that our skills are in such demand and that there are ample opportunities out there for us. So whether it's seeking better opportunities, or seeking an improvement on the current situation, we're so fortunate that most of us have the opportunity to make changes.

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
ky1e_s profile image
Kyle Stephens • Edited

Thanks for reading :)

I don't think any role will ever be perfect. It's great you work with great people and are rewarded for your work.

On your point regarding user perspective, I'm not sure whether you mean A) validation that the features delivered succeeded in achieving their goal or b) you would like to understand the tangible benefits to the user of the features being proposed before you develop them.

If it's A) there are some great analytics tools out there. I'll be happy to let you know what I use if you'd like.

If it's B), a first step might be to suggest that requirements are written in the form of User Stories, if they're not already, so that developers can understand what value a proposed feature will bring to a user, instead of "feature must do X thing". Beyond that, it's probably a matter of making suggestions to amend the processes, if processes exist, so that developers are more involved in understanding the business and not simply writing code. If no formal processes exist and you would like a bit more structure, why not be the person to float the proposal? ;)

Collapse
 
Sloan, the sloth mascot
Comment deleted
 
ky1e_s profile image
Kyle Stephens

Because you mentioned lacking user perspective, I was more thinking along the lines of validating that value has been delivered to user post-delivery, via heatmaps/analytics/A-B testing and things like that.

I wish you luck with advising on the processes. It can be a rewarding experience - particularly if people start seeing faster deliveries and better deliverables.

Collapse
 
luisventura profile image
Luis Ventura • Edited

Oh boy do I relate... Actually my last job/workplace went through exactly these stages, one after the other in the course of three years. Madness! but honestly I think this wouldn't have happened if I had been better prepared by then and consequently had countered every situation.

Collapse
 
ky1e_s profile image
Kyle Stephens • Edited

So, do you feel you had the scope to influence change yourself? Sometimes, particularly in larger organisations where meaningful change must come from the top, I've found that this isn't always the case. However, I do think it's always nice to view these situations through the lens of "there's opportunity in challenges" - whether that's opportunities for personal growth and learning or opportunities for advancement by demonstrating leadership through helping to own and resolve known issues.

Collapse
 
luisventura profile image
Luis Ventura

I believe I was in position to make it better, and even though the 15-employee company is doing well, it would be miles away when I had a somewhat privileged spot. It was a lot of experience, a lot of "never let this happen again" experience, and "fight when you know you're right, humble down when you're not". By the time I quit out of suffocation, I was juggling with too many things that kept me from delivering an acceptable degree of quality, missing milestones and it was a constant fire to fire situation. I think I learned my lesson big time.

Thread Thread
 
ky1e_s profile image
Kyle Stephens

Thanks for the candid response. Every experience is an opportunity to learn, right? Both in terms of personal preferences regarding work environments and also in terms of personal skills approaches and to work! Hope the new role is going better ;)