Last week, we examined some common myths about time. Did you know that software also has hero myths? These are mythologies that have crept into development practices that ultimately have a negative impact on teams. Normally, we like to think of a a hero as someone admired for their achievements that overcomes adversity. They “save the day”, rescuing others from imminent dangers. In software development, however, a hero is often a problem.
Think of an orchestra. When one is producing music correctly, all of the instruments are driving towards common objectives in perfect balance. The tones blend together to create the melodies and harmonies. If one player tries to handle the challenge on their own, they stand out. While they gain attention, the overall product suffers from their misalignment and from their sounds and interpretations contrasting with the team’s efforts.
Software is similar. When a single person continuously stands out, its often to the detriment of the team. In most cases, they are not a hero by choice. They are put into an uncomfortable position as a result of poor leadership or an abusive environment. Instead of contributing to a thriving lifecycle, they stand out for making progress in unhealthy ways. In the worst cases, they are not along – they are part of a team of heroes.
The hard-working hero
Many developers feel that the best way to succeed and be productive is to work more hours. In abusive work cultures, dysfunctional management teams take advantage of this to encourage these heroes to sacrifice for the company. This is very common in startups; teams are encouraged that one more push (or working in “crunch mode”) will allow the company to get to the next level. In truth, that rarely (if ever) happens. Instead, the cycle repeats again. At its root, this hero is created based on the myth that more hours yields more progress faster releases. It’s an abuse based on the fact that salaried workers seldom get overtime pay. And its based on a false premise.
For more than 100 years, industry has recognized that excessive work hours has diminishing returns. In fact, the industrial revolution was partially driven by a need to reduce working hours. They recognized that after 40 hours of work, progress was reduced and error rates increased. This trend increased with the number of hours. Most research demonstrated that productivity peaks around 32 hours.
In 2022, a UK pilot program proved out this research by testing a four-day work week. Approximately 46% of the companies reported productivity was unchanged, and 49% reported it had improved. Only 6% of companies saw any decrease in productivity. In addition, 44% of those companies saw their finances improve with the change. Employees were less fatigued and more refreshed, so they were able to create better quality work in less time.
A Stanford University study in 2014 demonstrated that productivity declines most significantly after 49 hours. After 55 hours, additional time is generally unproductive. After 60 hours, the resulting errors can result in an overall output similar to working only 40 hours. Worse, the mental and physical exhaustion can continue for several days afterwards.
In 2005, IGDA published a whitepaper documenting historical research of extended work hours. The author wanted to demonstrate that these challenges were previously recognized. In that paper, they cited:
- Sidney J. Chapman’s Hours of Labour (1909) documented that any output produced after extended hours is offset by declines in productivity the following days.
- Hugo Münsterberg’s Psychology and Industrial Efficiency (1913) documented an increase in productivity after shortening work days from 9 hours to 8. That is, a 12% reduction in hours led to an increase in output.
- Henry Ford reduced the work week from 6 days (60 hours) to 5 days (40 hours) in 1926 based on internal productivity research. He saw a significant increase in productivity and reduction in costs. By 1933, the 40-hour work week was established throughout the US.
The article references a 1980 study from CURT examining differences in work output between 50-hour and 40-hour work weeks. With each passing week, the team working longer hours saw productivity decrease and costs increase. By the sixth week, the productive output of both teams was briefly identical. After that, the 40-hour team was more productive.
More telling, the percentage of hours where the 50-hour team was productive shows a characteristic decline from fatigue, dropping by 25% around week 8. It’s worth observing that 80% productivity equates to 40 productive hours.
In short, longer hours reduces the quality (and quantity) of the work produced. Remember the fable of the tortoise and the hare? Turns out that lesson applies to office work as well.
The transformational hero
One of the most frustrating things in development are people that think development roles are interchangeable. I remember situation where a team needed database expertise for a problem. The executive manager said to ask one of the web developers to handle the issue. Trying to explain why an HTML specialist would be challenged to identify performance issues in a database was a losing battle. “But … he’s a developer, isn’t he? He should be able to figure it out, right?”
I asked the executive to imagine he had been told he needed immediate heart surgery to live. Who would he call to help him? “The best heart specialist I could find, of course!”. I was confused – why not call his dentist? Or the family doctor? “They don’t have the right skills,” he replied. “But they’re all doctors, aren’t they? They should be able to figure it out, right?”
While it is true that developers love a challenge and learning new things, building skills takes time. Ideally, it also requires some guidance. Expecting a developer to be responsible for work outside of their expertise (especially without a mentor) is a recipe for late nights, long weekends, and failed projects. On top of that, it creates stress and friction for everyone involved. To be successful, pair the developer with someone experienced. This enables them to learn without the pressure of the entire project and creates a path for developing the needed expertise.
The inspirational hero
This is one of the most dangerous mythological heroes. This is the person that must be seen as always making a release happen. They always deliver, always on time. And for some reason, they seem to get the benefit of the doubt. The problem with this hero is they don’t rely on continuous improvement. Instead, they focus on saying what they think each team member wants to hear. This sets unrealistic expectations with management, creates complications for the team, and builds a culture of dishonesty and distrust.
As an example, I recall a team lead that told management a key new feature would be ready in 2 weeks. At the same time, he discussed with his team that the feature was more complex than anticipated. The most experienced developer estimated that the functionality would need at least 12 weeks to finish. The lead continued to tell the other teams and managers that the project was on track, while telling the rest of the developers that he was working to set appropriate expectations. Despite these assurances, the development team was criticized by management for never meeting a delivery date. Management tried to adjust plans and priorities, but each change pushed the project further out.
The problem was not just the individual or that the management team continued to allow these situations. This highlighted a lack of communication. When communication is restricted or siloed, information exists in a vacuum. When development practices are open and transparent, it makes it harder to create misinformation or misdirection. With a light shined on the underlying issues, teams are able to then focus on solving problems and implementing features. They learn to work together to create better software. The teams develop trust.
The expert hero
We’ve all seen this hero in action. The person on the team that has an answer to every question and a solution to every problem. Highly critical of others, they are more than aware that they are the best in their field. More importantly, they are determined to preserve that image at all costs. They don’t mentor or guide others; they look for ways to bring them down.
A wise leader once told me that he would rather hire three people that know nothing and have a positive attitude than one person that nobody on the team wants to work with. What’s the point of having someone that’s the best at what they do if nobody wants to be in a room with them? This “expert” brings down the morale of their coworkers. This lowers the team’s productivity. Ultimately, they reduce the ability of the group to deliver.
Sometimes understanding the negative impact they are having will help these heroes to put things back in perspective. To change their approach, they need to be in a company that makes it safe to fail: a blameless culture. Failure is treated as a learning experience. It’s celebrated. It’s safe. When everyone can make mistakes and try new things without a fear of punishment, it can allow them to open up to new ideas and approaches. The expert hero is often terrified of failure and afraid of punishment or embarrassment. Making it safe for them to make mistakes can make them more comfortable working with others. Working with others, they can share their experiences in a healthy way while learning from their coworkers.
There are no heroes
The mythical hero experiences take away from that sense of community. The hard-working hero creates an unhealthy work-life balance, leading to burnout. The transformational hero struggles to find success, while the team continues to suffer from missing expertise. The inspirational hero thrives on a culture of dishonesty and misinformation, while the expert hero drives out top employees and indirectly sabotages projects. In each case, they are a symptom of an unhealthy environment and a need for immediate change.
At the end of the day, employees want to do their best work. With proper expectations and a healthy environment, the collection of people becomes greater than any individual member. Complimentary skills and points of view build up the collective team. Their talent grows more quickly as they learn together. Without mythical heroes, the team finds its own path to becoming capable of extraordinary things.