Scene: Surprise meeting with the project owner 0-3 days before the go-live date
“Hey team, the business and I have decided to postpone the project release by n=1-3 months because [they aren’t ready for it / it isn’t finished /regulatory reasons]. And since we have some extra time now, we can tie up all the loose ends on this project (i.e., ‘we’ve added n+1 months worth of backlog items to the MVP’).”
I’m still a greenish dev, so maybe this is normal, but I’ve had the same story going on for over a year now, and it’s really starting to burn me out. In the beginning, I was optimistic. Now I just hope for the project to fail, or me to get off somehow, but this thing just won’t die.
Anyone with experience on similar projects able to share words of advice? Do they ever end up working out? Seems there’s a death spiral, since we are always rushing to a deadline, forgoing tests and quality but never cleaning up our mess because we’re already behind. Yet I somehow feel like I’m the crazy one for thinking this 6-month “quick” side project turned 2+ year half-rewrite will have trouble meeting it’s Nth deadline.
Yes, considering it as a paid education always helps. I don’t really think of anyone here as a mentor, so I usually have to study on my own to learn what I need, and I still tend to regret most design decisions I make. And there’s just that looming feeling that everything I’ve worked on is ultimately worthless. But I guess all of this is just part of the software development job, ha.
Interesting that you say jumping damages the personal image, since it seems what most others here advocate. This job gives me good perspective, so I still wouldn’t want to go elsewhere without convincing myself that it’s a meaningful improvement.
As long as you’re learning and getting payed it is worth it… in some cases it even goes further to “as long as it pays good”.
Let me explain why, from the perspective of a developer who eventually transitioned into management: Occasionally, even seemingly futile projects yield results, and the company manages to ship something, albeit subpar. If you decide to abandon ship before the project’s completion, you risk being branded as unreliable and weak minded.
Projects that linger are often sustained by middle management’s relentless promotion of a particular narrative or by their skillful manipulation of senior management (bullshitting). This persistent advocacy creates a perception of the project being incredibly challenging, yet the “highly competent” middle manager successfully sees it through.
Once the project triumphs, any prior skepticism dissipates, but the narrative of its formidable nature remains, and the middle manager continues to champion their foresight, claiming, “As we can see now, I was right about this project. It was nearly impossible, but our exceptional team delivered, and here we are.” All parties involved receive rewards, while those who departed before the launch are often perceived as weak by their peers.
The job market is small, and having a reputation for bailing when things get hard is bad. What we witness in software development mirrors broader societal dynamics—in the past, survival hinged on confronting danger and often dying, whereas today, it’s more akin to a waiting game to see who commits suicide first. Exiting such projects is akin to playing “Russian roulette” with your IT career because regardless of the project’s outcome, remaining loyal to the company and sticking with the project is typically a safer bet.
Side note: Occasionally, a middle manager may push everyone into quitting, thereby shifting the blame for the project’s failure onto the workforce and paving the way for securing additional resources or personnel to then covertly overhaul the project and deliver something.
Thanks for the response. I agree that the project’s big boss has an impressive ability to BS on the greatness of our project, and it may be enough to push the project past the finish line.
It seems you put a lot of weight on the project’s “triumph.” If the project fizzles out or fails spectacularly, does that not make you more of “the fool who couldn’t do it and didn’t know when to quit?” I don’t think I’d hold it against my coworkers for leaving if they think it would improve their situation. (And doesn’t a sound project plan account for the fact that you may lose people every so often?)
Interesting note about small job market though. I only have a ~20 person IT department without much churn so it feels quite small to me still. How do you see this reputation spreading? Just the diaspora of former coworkers is wide enough that most/many companies tend to have someone who knows / has heard of you?
I see your point however you’ll be covered by the dynamics of the organizational hierarchy. When the mid manager’s ability to bullshit senior management eventually runs out then the project will fail, not because of technical reasons, but because the senior management will terminate it. The mid manager will then get reassigned to somewhere very far away and you’ll get a new project with a different manager.
In teams with three+ developers, the one who often bears the brunt of failure is the middle manager, not the workforce. Senior management typically holds the middle manager accountable for the project’s shortcomings, rather than the individual contributors. As long as you fulfill your duties (do whatever is asked), your reputation will remain intact, portraying you as someone who consistently delivers without giving up.
At the end of the day it boils down to the waiting game: who will quit first or run out of bullshit. This is the dynamic within most organizations and ultimately, individuals who “do whatever is told” and never quit tend to emerge as unscathed heroes.
A guy knows a guy that know a guy… reputation plays a significant role and even seemingly innocuous comments “yes he was at my company for 1 year and he seemed like a nice guy but then he left before delivering his first project” can have far-reaching consequences.
Moreover, burning bridges by leaving a company before delivering a project can indeed makes it next to impossible to return in the future. Maintaining a good relationship with former employers is crucial, after all you never know when you may need to go back to some company.
In a smaller or medium-sized city where good IT job opportunities are limited, burning bridges will significantly impact your future prospects. Each negative remark or unfavorable departure from a company could potentially close doors to employment opportunities permanently.
Consider the following: 15 out of those 20 people, at some point, leave the company and while they “know you”, they never worked on the same project. This may lead to those seemingly innocuous comments and burning job opportunities at 15 different companies - a considerable percentage of potential job sites in some places.
Also there’s the issue of recruiters. They may look at your CV and if they see a bunch of companies in a short period of time they’ll most likely favour other candidates.