>An ideal solution to this would have been to just go talk to the stakeholders - product/sales team - ask them if the delay could be potentially customer losing. And if it is, by all means put in the extra hours, work those weekends.
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
Definitely. That's phase 2 of the world's worst game. Phase 1 being "Please give us an unbiased estimate, but we will yell at you until it's the number we like." Under those conditions, working weekends is just feeding the beast.
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.
I was lucky enough to see management get caught in their bullshit during one of these "hard deadlines" when I was just out of school. They said that December 1st was the deadline and that if we didn't get the release out we would lose millions in revenue. People run around like crazy until the end of November when we realize the EULA document is just a place holder and that Legal has not given us the new EULA. All of a sudden the deadline is mid January when we expect to get the new EULA.
What drives me crazy about this is how it shows that some employees are expected to bust their asses to meet deadlines, but others (legal) are not -- oh, if legal won't be done in time, we'll just move the deadline, no problem.
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.
Right, because the promise the developer is making(in most cases) isn't to to stakeholders or the users but to project managers. If the PM can't fulfill their promises on time, that's on them. Their responsibility is to better estimate what can be reasonably done in a time frame, provide buffers where possible, and shield developers from the business responsibilities that go above them. PMs and stakeholders need to be able to adjust their expectations to reality, not punish their developers by working longer or harder, or by changing the makeup of their development team, because it's not the minutes-spent or # of lines of code that make a good product.
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.
Have to agree here. I sometimes find quite a big gap between deadline setters (sales/management) and the ones who have to meet them (developers).
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.
I've ran into this with teams before. I think it's critical to ask ourselves "Who really are our stakeholders?". More often than not, the answer boiled down to a.) our customers and b.) our sponsors. If someone from sales, marketing, support, infra, or anywhere else lobbies for anything that'll turn into work, we work with our PO to make sure this is something the product team (customer by proxy) or sponsor(s) really think are important.
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.
If the sale is easy it’s because the lead thinks like your existing customers. If the sale is hard, it’s because they don’t.
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.
If we read between the lines that means the layers of management are not needed at all if developers are talking to sales / users - see "Developer Hegemony" and "Developer Anarchy"
If you make other people's planning problems your own problem, then over time everyone who planned poorly comes to you to save your day, and you burn out.
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 agree with your disagree. Work at a sustainable pace and if all your stories are slipping to the next sprint every time then you know you are underestimating. Likewise if you never slip you are overestimating. Forcing people to always finish each sprint will either burn out your team or cause estimates to be far too conservative leading to slower progress. That said, there are actual dead lines, where if you are late the software is useless and you are going to be returning a customer's money, or at best losing a customer's confidence. Those deadlines don't happen every two weeks.
If you are selling through sales people, and have enough new customers, then it’s possible to have a situation with a deadline every few weeks, unless someone intentionally brings sanity into this process.
The only time I've come close is when we fostered a culture of continuous improvement. We don't want to just produce features faster. If that's all you ask for you get people finding new and better ways to cut corners.
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).
One thing that leads to those faulty promises, IME, is that we often conflate estimates with commitments.
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.
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