January 22, 2022
I’m generally not a fan of all the criticisms of “hustle culture,” but my developer Spider-sense is triggered whenever I see a company complimenting heroic actions on project teams. Any time I hear phrases like: “The team really had to put in the nights and weekends,” ”_________ worked all weekend,” or anything referencing burning midnight oil, I cringe a little.
I’m not against hard work. I understand that sometimes you need to throw down a few extra hours to get something through the gate. What I’m against is seeing that as a good thing. Heroics are not a cause to celebrate; they are a red flag.
Consistent long workweeks contribute to high turnover and burnout. Finding and onboarding new team members is expensive. This is especially important when a single team member performs the heroics to keep the project moving. When that person leaves, you’re in a considerable amount of trouble.
If you want a dynamic organization of people from various backgrounds, pay attention to work-life balance. Not everyone on your team can work tons of hours. Many people have family responsibilities, and encouraging heroics pushes those people out of your organization. If your goal is to employ a crew of single 20-somethings that all resemble each other, then you don’t need to worry about this one.
Extra hours bring diminishing returns in productivity, eventually reducing overall productivity. Those late-night code changes are probably not going to be the best work. As those poorly implemented changes add up, your codebase becomes less maintainable, further slowing down development.
High-pressure situations where people are constantly tired and burnt-out lead to low-quality products. It’s hard to care about your customers when tired.
One of the critical tenants of agility is creating a sustainable workflow system. You build an engine of work; you continuously enhance it through automation, team cohesion, and refinement. Over time, the 1% improvements add up to a high level of productivity. Everyone wins.
Heroics throw a wrench in that system. It’s an indicator that something needs to change. Here are a few places you might want to look if you’re trying to increase your workflow:
When using sprint-based frameworks like Scrum, it’s easy to underestimate work and overcommit in a sprint. Misestimation is especially easy if the development team isn’t estimating or setting their sprint commitment. Also, realize that getting a consistent velocity will take a few sprints when projects start.
Use automation to reduce the number of interrupts in your day. If you must do it consistently, write a script to automate it. Even small tasks can break you out of the flow.
Lack of clarity is a giant productivity killer. It’s much harder to do a nebulous task than a well-defined one. It’s much harder to test a sizeable nebulous task than a well-defined one. This lack of shared understanding causes work to bounce around the team as everyone figures out a shared definition of the work. Spend time refining work to small achievable chunks.
Rehashing discussions is a productivity killer. Spend a little extra time to document some standard practices for your team. Create checklists or refine your Definition of Done. Documentation also helps you with onboarding since you can point new folks on your team to the docs.
If you rely on a single person to do specific tasks on your team, that person will constantly be bottlenecking your team. Spread that knowledge around through documentation or pairing. Similarly, work to find and eliminate gatekeepers.
Your team should be able to complete work without relying on other teams. If another team regularly blocks your progress, spend some time with them to automate that process or eliminate it. It isn’t easy, but it usually pays off.
Heroism may make for exciting stories, but exciting stories don’t create excellent software. Hard work is essential, but if your project relies on heroics, it’s time to make changes. Look at your processes, find bottlenecks, and work to reduce or eliminate them.