The Myth of Long Hours
tldr; a team working long hours is far less efficient than a well planned team in sync.
Over the last month, I’ve been interviewing for technical leadership roles in a wide variety of situations: from huge teams at some giant companies, to startups that are little more than a wish and a prototype. And, unexpectedly, the process of talking to all these companies and trying to figure out where I want to work has really brought into focus a lot of ideas I’ve been building up over years of managing teams and working in technology.
A common belief in Silicon Valley (more than SF) is that working long hours is sign of virtue for a startup. The belief is that it’s a good sign if everyone is working late and on weekends. The reasoning is that you don’t have a lot of money and you have to “catch up” to the competition. The more hours your employees put in, the better deal they are! You get 2x the value if you can convince them to work harder.
If you have engineers working overtime on a regular basis, then you’ve fucked up. Of course, the “you” I’m referring to here is leadership, not the employees. If your team is panicked, behind schedule, in chaos, and having to burn the midnight oil on a regular basis, then you need to seriously change some stuff about how you are managing.
Engineers who are overworked come up with bad ideas, have low overall velocity, and often end up with overly complex and bug-laden code. They will eventually burn out and will leave you with a lot of badly-written code that no one on the team knows how to work with.
The job of technology leadership is to set a clear direction with an optimistic timeline that allows for tolerance if things go awry. If you have a dedicated team who are well rested and are given time to fully understand the overall plan, then you’ll rarely see them feeling panicked.
To be clear, occasionally shit hits the fan and long hours inevitably follow. A giant deal comes through! There’s a huge outage! Argh, a security issue! We get mentioned on the front page of the NYT! Those things totally happen and it’s a part of working in a startup. The problem comes when it becomes the norm or… *gasp*… is lauded.
Each time one of those things happens above, it’s my job as a manager to figure out how to make sure it doesn’t happen again. If a huge deal unexpectedly comes through, then next time we need to communicate better with whoever is making those deals. If we have an outage, we need to figure out how to change the processes in the business that lead to that outage. The same follows with a security issue and with getting unexpected traffic.
Each one of those is an opportunity to make the living, breathing organism that is your company more resilient to crisis.
I’m not championing this concept because of a moral good. I mean, of course it’s nice to be a good person, but I think long-hours are bad for your company and actually slow velocity. Working long hours makes a lot of noise, and sure looks impressive, but your team is not moving as fast as they look like they are.
Building technology is a team activity. It’s not chess or sudoku. It’s more like a sport I used to do, which I think takes the cake as the most teamwork oriented sport on the planet: rowing. I know, I know… sports analogies. But, stick with me here, and I promise you’ll have a new way to look at the teams you work with.
In rowing, strength is important, but it pales in comparison to the team being synchronized, timed, and well directed. In order for the boat to move forward quickly, everyone must be in exact time and (obviously) they should be pulling in the same direction.
When I used to row, I was the “stroke” on the boat, which is the rower that’s furthest to the back. I sat next to the coxswain and it was my job to keep everyone in time. There was no rower in front of me to follow, so it was my job to keep a consistent, metronomic time that I could vary while talking with the coxswain. When boats are moving, the stroke and the coxswain are in constant communication, figuring out if now is a great moment to speed up the rhythm or slow it down.
This is a lot harder than most rowers make it look! As you move, the momentum of the boat is pushing you forwards really quickly, and it takes a lot of strength to stop yourself from rushing forwards too quickly.
The gif above shows just how fast you can go. No one is exhausted or sweating or grunting or out of control. The winning teams are made up of people who are in control, focused, and look like they are taking it easy – all while going incredibly fast.
Alternatively, the gif here is an example of a very novice team who are way out of sync. Everyone on this boat is pulling as hard as they can and they are fighting each other! The boat makes little movement.
One rowing stroke done right goes further than 10 strokes out of time.
And this is exactly how I think about running my teams. If people are working with panic and overtime, then we’re not moving quickly. Sure, we’re making a lot of noise, but any real progress is extremely slow.
I don’t think I could find an appropriate rowing image that explains how dysfunctional most engineering teams are. You’d have to place some rowers backwards, all rowing different directions with the coxswain screaming and the boat churning a lot of water and not really moving anywhere. That’s a pretty typical scene in some companies.
Measure overall team velocity with clear goals and timelines, not hours worked. (Later, I’ll write about why focusing on individual performance is not as good as focusing on organizational performance!)
There are certainly companies where no one gives a shit and no one works hard and it doesn’t really matter, but that’s not something that a startup is likely to face for a long, long time. I’m assuming that most of the employees that decided to join your company are passionate about what you are doing. If you’re hiring people who are only there for the thrill of being behind schedule, then get them out the door ASAP!
The real issue is making good decisions every day. A company is the sum of all the decisions made. The quality of those decisions is the primary determining factor of your company’s success. Telling a room full of people to spend 12 hours making decisions constantly is going to result in a bucket-full of bad decisions.
I’ve never worked with someone who can code more than 4 hours a day and keep their velocity up. Actually, 4 hours is being optimistic… that’s a day when they get good work done and feel focused! Some days it’s zero!
When it comes to productivity and quality, I’ll wager that my team who codes 0–6 hours on a typical day and knows exactly what they are working on — and why — will absolutely destroy a team who works 12 hours a day.
Stop bragging about how fun it is when your house is on fire. Make a plan, stick to it, communicate, mentor, and train. Working like that is relaxing, enjoyable, and (most importantly) means building totally badass things on schedule that work as they are intended. You know… engineering.