Strongly disagree, it's not on the shoulders of developers to ensure faulty promises can be kept. I will for sure not sacrifice weekends, this is far from ideal
I do think it can be ok to work extra hours to seize an unusual opportunity or deal with some truly unexpected problem. (E.g., the destruction of the World Trade Center in 2001 required a lot of tech people to scramble.) But that has to be balanced by something good for the workers and painful for the business, like an equivalent amount time off or significant overtime pay.
But workers shouldn't have to spend their spare time making up for managerial incompetence and malpractice.
"Did a bomb go off in our datacenter? No? It can wait then."
While some people -- healthily or not -- are willing to bust their butts (with or without extra compensation) when they think everyone is in it together, it will generally kill morale and willingness to do such when you realize when someone else 'doesn't have time', the deadline is moved, it's only you expected to work evenings and weekends and extra hours to meet the deadline. Why is your work-life balance less important than theirs exactly? (Only because they can get away with it...)
And while not always as stark as your example, people are often shown this all the time, that not everyone's inconvenience is in fact treated equally, that the "deadline that can't be missed" really only applies to some people, and is moved for others.
Beyond that, working extra hours and weekends is a bad idea. It should only be done out of desperation because working overtime can quickly become the expectation.
Granted, the lines can be pretty blurred at some companies, namely startups that give lots of responsibilities to their developers. But most non-startups seem to have more refined command structures.
I find it to be a very difficult topic, as everything has to coexist: no sales, no company but no developers no product to sell which is then no company.
I find that the deadline setting sometimes gets out of hand because it's not the setter who has to meet the deadline. For example if I set a deadline you have to meet and I can not influence the work being done (help or somehow make it easier to hit the deadline) how could I ever understand the "true" consequence of setting the deadline? In other words, not my weekend so I probably won't care as much as you.
What has worked for me (sometimes) is setting up the consequence; if we have to make x for deadline y, we won't be able to make a for deadline b. And then try and involve "sales" or the deadline setters in how we cut down whatever has to be made so we do make the deadline.
But that completely aligns with the post as that rarely is user centric or building the best solution for users. This simply gets stuff done within an arbitrary deadline set by someone, to meet a contract etc.
Bear in mind these experiences are from startups and not corporates.
Time and time again we've butt heads with the sales team because they promise the world to one or two leads before checking back in with reality. Those interactions are met with checking in with stakeholders to validate assumptions. we gained the support of our executive sponsor or customers who are actually paying for the product to be built. Asking that question insulates us from greasing internal squeaky wheels.
Any feature you use to entice a new customer isn’t necessarily going to please your existing base. It might, as someone else suggested, actually be a considered a liability.
So the idea of building a new expensive feature, or a new feature in an expensive way, is suspicious. There’s no guarantee you can amortize that cost across all of your customers. And the times we really butted heads with sales? The features cost us more than the value of the sale, reducing margins.
But I suppose that’s the sort of metric dysfunction you invite in when you measure salespeople by sales.
And then you're somewhere crying on the floor or in a hospital, and not coding. The organization around you has adopted to poor planning, because you encouraged them to do it.
"I'm not wasting this food by throwing it away, I wasted it when I let it go bad in the refrigerator"
If we really do care about the customer, we should be fixing the problem at the source, not trying to scramble to fix things after it's too late.
Learning productivity tricks and building tools actually lets you do the same amount of work in less time. Some quality initiatives reduce rework, which also increases throughput. And these practices also reduce stress during exceptional events (production issues). That effect may be mostly obvious but what we don't ever talk about is the fallout of stressful events and how they affect the quality of the code produced immediately afterward.
Burnout, as you say, is the end game of not doing this. But I think the symptoms are detectable long before that point (and I might argue are part of the feedback loop that leads to burnout).
When you work in a scrum team with a well-established workflow, and you have the experience that we usually finish around 20 story points per sprint, then shouldn't commit to finishing the next sprint with 20 story points.
You also know that that effort and technical challenges etc. vary greatly, so you can only do a commitment to, say, 8 story points per sprint with a straight face.
And now, try to tell somebody why you only commit to "so little" work being done by the end of the sprint when you tend to get much more work done... Mostly impossible, in my experience.
I want to meet the person who went around convincing PMs and scrum masters to abandon the word "estimate" in favor of "commitment".