When is it time to leave?
Tags: career
Published: 2018-01-15 15:48:28

---
title: When is it time to leave?
published: true
description: How do you really know when it’s time to call it day and move on?
tags: career
cover_image: https://thepracticaldev.s3.amazonaws.com/i/03drbskt1f1kaedbnnza.jpeg
---

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](https://thepracticaldev.s3.amazonaws.com/i/y4udiqvnfool6et8pahb.jpg)

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](https://thepracticaldev.s3.amazonaws.com/i/x3ag92j5c9054goa3w6e.jpg)

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](https://thepracticaldev.s3.amazonaws.com/i/dwti7ejeibsma9d73de2.jpg)

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 **Hi**ghest **P**aid **P**erson’s **O**pinion), 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](https://thepracticaldev.s3.amazonaws.com/i/3d69ryhhrhvq38chw7p9.jpg)

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:

- [Agile and Lean Program Management: Scaling Collaboration Across the Organization](https://www.amazon.com/Agile-Lean-Program-Management-Collaboration/dp/1943487073/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=&sr=)
- [User Stories Applied: For Agile Software Development](https://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685/ref=pd_bxgy_14_img_2?ie=UTF8&psc=1&refRID=Z8DB6T32DAKBN6YHTSNG)
- [Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition](https://www.amazon.com/Coaching-Agile-Teams-ScrumMasters-Addison-Wesley/dp/0321637704/ref=zg_bs_379406011_5)
- [Essential Scrum: A Practical Guide to the Most Popular Agile Process](https://www.amazon.com/Essential-Scrum-Practical-Addison-Wesley-Signature/dp/0137043295/ref=zg_bs_379406011_2)
- [Agile Project Management with Kanban (Developer Best Practices) ](https://www.amazon.com/Project-Management-Kanban-Developer-Practices/dp/0735698953/ref=zg_bs_379406011_8)

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](https://thepracticaldev.s3.amazonaws.com/i/jkbmpbik9zktbbqt4cu3.jpg)

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](https://www.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!
- [Follow me on Twitter](https://twitter.com/Ky1e_S)
- This article first appeared on [Tabspace.io](https://www.tabspace.io)