Seven Signs Your Tech Job Is Awful
Software developers, or knowledge workers, as Peter Drucker put it, are in a position similar to a manager: their work is less about what they do and more about what they decide. The work takes place mostly in the mind and very little on the keyboard or in the physical world. Instead of testing their muscles or dexterity, developers test their brainpower and intellect.
In such a distinct environment, there will naturally be problems unique to that environment. If you’ve been in chair for a while and wondered if your technology job is exemplary, ordinary, or below average, here are a few considerations for if the grass might indeed be greener on the other side of the fence. These are not the only signs, but they are certainly among the most common. If you frequently wonder whether you could have a better job experience elsewhere, or think often about brushing up your resume, check out the below list and see how many you can identify with. Of course, all work is opportunity, and no job is perfect.
1. Not able to focus and get work done
When there are too many meetings, their apparent usefulness suffers from diminishing returns. The more meetings beyond a certain point, the more time they leech away where actual work isn’t being done. Scrum in particular is very vulnerable to this ailment. Yet scrum is always chosen without any thought of trying to keep meetings in check, or finding out what the developers actually need and want.
Meetings and meeting reminders are interruptions, pure and simple. Developers can’t be expected to accomplish a lot unless they have a large block of focus time on their calendar. The first thing I want out of my day as a developer is time to think and sip some coffee. The first thing on the schedule in every software job I’ve ever had? A giant block of morning meetings — in other words, plenty of context switching and interruption, and zero time to focus.
Kanban beats scrum hands-down at protecting the team’s focus and keeping throughput high — that’s what it was designed for. Why then is it so seldom chosen?
2. Lack of recognition
Code only exists when it’s broken — the default attitude of anyone non-technical talking about software and its flaws. If everything is working, it’s apparently not even worth talking about, much less appreciating the team for.
Few people will complain if they aren’t being recognized. They’ll generally keep their heads down and be glad they have job security, but their motivation will slowly deteriorate. Better to get ahead of the game and appreciate your team even if they don’t seem to need it. They do. The day you stop appreciating them is the day they might start wishing for a more fulfilling job.
3. Expected to be someone’s clone
Another anti-pattern that is far too common is expecting one person to be the clone of someone else. Each person is unique and should be managed individually, because each brings a distinct set of skills to the table. Skills can be learned, but not everyone will have the same natural affinity and proficiency for the same things. Not everyone is motivated by the same things, either — or for the same reasons.
Requests along these lines are often a sign that a manager doesn’t understand the need for different roles on a team. It can also mean they are unable to distinguish between the roles and see who is filling which role and appreciating the individual value and contributions of each person.
Cross-training is a great goal to have, but care should be taken that it isn’t over-prioritized or over-emphasized. Demanding the same skill levels from everyone is unreasonable and can make people feel misunderstood and unappreciated. No one likes to be compared with others. Rather than focusing on what someone can’t do as well as someone else, focus on their strengths and what they CAN do well, and appreciate them for it. If they need to grow their skills, give them the time and space to do it, and they will. Pressure them to become more like another person and they will move on and find a job where they are valued for who they are.
4. Not given time to eliminate technical debt
Ignoring technical debt really irritates me. If leadership won’t acknowledge the need to keep the axe sharp, they have no business running a software team. It’s a fundamental need and the longer it goes unaddressed, the worse the catastrophes looming on the horizon will be. In the software world, ignoring technical debt is a bit like trying to defund the police. Keeping things in order and running smoothly is a simple, matter-of-fact requirement in every project. Technical debt should never be the top priority, but it shouldn’t be growing mold all the way in the back of the fridge, either.
If you don’t have time to pay off tech debt, when will you ever have time to work on preventing it?
Give me six hours to chop down a tree, and I will spend the first four sharpening my axe.
-Abraham Lincoln
5. Schedules not taken seriously
Too many meetings are bad enough, but sometimes they spill over and run together like uncooked egg yolks. If we’re going to hold a large number of meetings, then let’s hold them and stick to the schedule. Otherwise, why bother using a calendar? Once in a while is fine, but when every late morning meeting bulldozes your lunch plans, it’s time to take a step back and reconsider priorities, not to mention your personal health.
Another example: rarely you may encounter a team or organization offering developers the productivity-boosting “meeting-free” day, only to have it trampled upon and casually used for meetings anyway. Again, you can’t be serious about something and not serious about it at the same time. Either do it and then enforce it, or forget it about it entirely.
6. Over-promotion
Often in software development, a high performing developer gets promoted to management. In itself, that’s not a problem, as long as they see themselves as a servant leader and work to improve their manager skills as they step into that role. But sometimes they get over-promoted (beyond their capability). To be fair, very few are capable of being a great manager and a great senior engineer at the same time.
Having risen through the ranks being told they are awesome, which is of course true of their developer skills, some assume they will be just as awesome at being a manager. They then begin to dismiss any negative feedback assuming it’s just a phase and people will eventually grow accustomed to their management style, not realizing that being a good developer and being a good manager are two very different things.
Having the experience of being a developer can help with management, but it’s fundamentally a different job. Even in those cases, it seems that having an office of their own flips a switch in a person’s brain and they forget what it was like to write code. Profits and manager-speak begin to swirl inside their head and they lose empathy for the developers. I even read an article by someone admitting that as an executive, he became the exact manager he hated when he was a developer: micromanaging and pressuring the team to deliver more faster. Speaking of which…
7. Long (e.g. accurate) estimates frowned upon
Software development can’t be rushed without spoiling the end result, but it usually is rushed anyway. Then guess who gets blamed for the product being low quality? The developers. After the fact, pointing out “you rushed us and we warned you this could happen” is only seen as an excuse, never taken seriously as the very cause of the problems.
I hope that if we ever have AI capable of programming, someone builds logic into it to call out management on such decisions: “I’m not the janitor — clean up your own mess!” It’s not so easy to argue with a computer. Go ahead, threaten to ‘fire’ Copilot or ChatGPT and see how it responds.
Summary
If you identified with most or all of these in your own tech job, you might be able to find a better position. However, doing so will be its own challenge. It comes down to stability. Is it truly that bad, or can you deal with it? Maybe the above points are not a big deal to you.
In my experience, having to deal with too many of these types of issues causes a lot of contention and frustration in the workplace. These in turn can fester into work intake problems, damaging role clarity and team motivation, and cause major delays and setbacks.
I’m not suggesting that any one of these is worth leaving your job over. But when several such problems are your day to day reality as a developer, the excitement of a new role, freedom from current headaches, and the promise of a more enjoyable workday start to seem better and better with each bloated meeting, ignored contribution, and denied request. There is nothing wrong with desiring and searching for something better. There is also something to be said for being thankful and looking for things to appreciate about your current role. Whatever it is you’re looking for, here’s hoping that you find it.