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
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
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
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
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
- User Stories Applied: For Agile Software Development
- Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition
- Essential Scrum: A Practical Guide to the Most Popular Agile Process
- Agile Project Management with Kanban (Developer Best Practices)
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
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!
- Follow me on Twitter
- This article first appeared on Tabspace.io
Top comments (37)
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.
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.
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?
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 :)
Thanks for reading :)
This offers a lot of introspection, speaking as an employer. Thanks Kyle.
Happy to share, Ben :)
I think that while both employees and employers can shape a workplace culture it's important that, as an employer, one takes a moment from time to time to step back, reflect, define, and evaluate the culture – both what it is now and what you want it to be in the future.
The above observations are based on my personal experiences and are ones that repeatedly popped up on different projects - I am sure there are other areas to consider, but, as I say, this is just something to stimulate ones thinking about happiness in the workplace.
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.
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.
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
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? ;)
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.
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.
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.
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.
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 ;)
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!
;)
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:
I'm glad I decided to leave but this notice time is awkward.
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.
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.
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?