There's been a big response to a comment Tim Cook said at the recent WWDC2019 event.
He applauded the engineers and other staff who gave up "nights, weekends, and time from their families".
It was a polarizing comment for sure. The response was full of mixed opinions about the way staff are treated and the way they're made to feel obligated to put in extra time.
In Apple's case, there were undoubtedly a whole host of complex reasons that led to people overworking to prepare for this event. Aside from the logistics of staging the event and inviting industry professionals and press, there's the significant pressure of being a company under such scrutiny (read as Wall Street) - that pressure would have been felt exponentially the closer they got to the deadline.
In other industries the pressure comes from clients. In some fields of law, as in the consulting game, the client is largely dictating the timeframe, and you end up with teams of people working days on end without breaks to meet a deadline.
Common sense would dictate that clients should understand that if your consulting team is working working around the clock and not sleeping, they're not going to produce the best work for you. However, the market does not run on common sense. The client also knows a price was negotiated, and if the team does not have enough staff to manage the project without overtime, then hire more staff. It's your problem, not mine.
I actually think the software development industry has done pretty well managing this problem because we enjoy a variety of methodologies that help us track and manage time throughout any given project.
With Agile, we can break a project down into sprints and estimate work fairly accurately. Agile has not only done a lot for making software development visible to the wider audience, but also for helping us avoid the so-called death-march: working all hours to meet some arbitrary deadline and screwing up our routine in the process.
I think building overtime into your culture is fundamentally wrong.
I think someone choosing to put in an extra hour or two to ensure a solid start to the following day or to build in some extra insurance for a future event is fine. As a developer, if I'm working on something and time's getting on, I'll secretly negotiate with myself to get to a certain point because I'll be so much happier tomorrow starting from a cleaner point. In a way that extra effort is locking in my motivation for a later time.
I'm also a fan of overtime being rewarded on a case by case basis. In contrast, you might be paid a premium knowing your consulting job means you'll be at the mercy of a new deadline all the time. You'll always be working overtime.
I much prefer the on-demand model - there might be an important demo and we might need to rally, but after that crunch period the team need to feel that effort is valued on an individual level. They should promptly be rewarded with time off (some multiple of the extra hours they committed) or extra pay (some multiple of their hourly rate).
Overtime is a common occurrence and often unavoidable but it's the relationship between employer and employee that is most important. No employer should take employees for granted and expect overtime as a given. Everyone has different priorities in their lives and you need to give extra when you expect to receive extra.
Let me know your thoughts! I'd love to hear about your experiences - whether you feel like you're taken advantage of or whether you feel suitably compensated when crunch time hits.
Top comments (10)
You said:
"Agile has not only done a lot for making software development visible to the wider audience, but also for helping us avoid the so-called death-march: working all hours to meet some arbitrary deadline and screwing up our routine in the process."
IME Agile "Scrum" produces nothing but a series of every two weeks death-marches to "complete the sprint". I've had managers tell me "You have to complete it. Agreeing to do it means that you will do it by the end of sprint no matter how many hours you have to work. You 'promised it'!"
This leads to overly cautious estimations plus tons of extra hours because the task turned out not to be as simple or straightforward as the requestor's description said it was, but since you "agreed" to do it in the sprint, now you are obligated to do it by the end of the sprint.
Then this leads to garbage commits, hard coded secrets, and other cowboy coder shortcuts just so you can get some sleep.
I think the standard industry implementation of Agile is deeply flawed, and contributes toward more overtime, not less.
I have long since realized that it is up to me to push back on uncompensated overtime expectations, because companies and management will never do so.
Thanks for your response and for the insight.
It's clear agile can fail when problems crop up and I think I've been fortunate in that in my experience the developer's have had the deciding vote on what goes into the sprint as opposed to the requestor.
You're right to push back though. Often the requestor has no idea of the complexity of a given task and is under pressure themselves from senior people desperate to see something shipped. If they're good at managing upwards, they can create room for developers to give accurate estimates and deliverables without obligation to the death-march.
I guess we're at least lucky that agile breaks a project down into sprints as these problems are exponentially worse in a waterfall environment where the scope is much wider with a lot less visibility.
Scrum is fine, garbage managers will find ways to be garbage managers in any possible framework
I totally agree! There are some times overtime seems necessary, but then you can relax on other times.
Also I do the same, as you described. Putting in some extra time to complete a started task or at least put in a state, where I can easily take over tomorrow. Which helps my motivation a lot the next day.
But I also learned that I have to review everything I did after 6h of concentration and throw away almost everything of what I coded after 10h.
Exceptions are, when I spend almost half of my day on the phone/ in meetings with others doing conceptual work, which somehow seems not that taxing as coding itself.
Andreas you make some good points. That's another thing that can be annoying in companies that adopt Agile: the additional time wasting (i.e. meetings) that are not supposed to be happening but inevitably end up killing half of your day!
Okay, I was going into the direction, that I don‘t have to throw away my code, even after 10h, when I was not coding the whole day.
But you are also right, a lot of meetings could have been an email.
People who use their heads need just as much sleep as people who use their bodies.
One of the worst things that exists in work is people bragging on how much hours they make. It is not a badge of honor.
I think overtime is avoidable. Just because you make up arbitrarily scoped deadlines does not make it overtime unavoidable.
It Doesn't Have to Be Crazy at Work
Absolutely, very good points Michiel.
1) Crunch is bad, full stop.
2) Tech workers need a union so they can push back
Yeah, I've been held to the sprint-ransom where my project manager would assign me tasks based off of pre-determined story pointing. If I didn't finish my work in 2 weeks, I was labeled as a slow worker.
I left that team and joined a team that used Kanban. Felt much less like I was on fire and enjoyed the work I did.
Later I joined a startup. Basically, we're doing Kanban-scrum, but with grind hours 6 days a week and 10 hour days (not to mention my 1.5 hr round-trip commute).