It’s almost inevitable. At some point your boss is going to pull you aside or ask in a meeting, “Can’t you make the team work harder?” Sometimes this is in response to a project that’s slipping, sometimes they just don’t feel that the team “has a sense of urgency.” After all, how committed could they be if they aren’t working 60+ hour weeks?
It’s hard not to feel like you’ve been punched in the gut. Your team’s output is your output, their performance your performance, a criticism of their work ethic an implicit critique of your leadership. It’s easy at this point to get defensive, or to jump to attention and try to “fix the problem.”
Before you react, you need to understand where the comment is coming from. Concern over hours in the office can be a proxy for a number of different things.
Total hours worked. Let’s just get this one out of the way. It’s worth asking yourself whether your engineers actually are working short hours. It’s easy to create an incorrect perception when shifting hours early to avoid rush hour and be home for dinner. Some prefer to grind during the day, others push it on nights and weekends. There’s a common bias that “being the last to leave” is equivalent to being a hard worker, even if you arrive late, and that leaving early means you’re slacking off, even if you’re in before everyone else.
Of course, what you should care about is results, not hours worked. But engineering time estimates are hard to get right, and even if someone gets all their assigned work done in half the expected time – hell, even if they do more – they’ll inevitably take more time than expected on something else later. And so we depend on hours worked as the best of a bad set of indicators. If your team is underworking, then yes, you need to find out why and fix the problem. But this usually isn’t the case.
It’s also worth mentioning that while an individual working short hours can be an indication of poor performance, an entire team underworking is almost certainly due to demoralization caused by structural, management, or project issues. Whether or not it’s your fault (and it frequently is), it’s your responsibility to fix it. Time to take a good look in the mirror, a big gulp of humility, and start listening.
Output. Is the concern that the engineers aren’t working hard enough, or that they aren’t producing enough? And how is “enough” being defined? Despite decades of research, engineering schedules resist precision, and it’s easy for even the best planning to be derailed by change requests, unrelated emergencies, stubborn bugs, and so on. Is the team behind because they haven’t been putting in the hours, because they ran into unexpected problems, or due to bad project management? Are they distracted? Is their productivity being killed by technical debt, a work-hostile environment, burn-out, or constant fire-fighting?
If your team’s output is significantly below expectations, then you really do have a problem – but it likely isn’t related to the number of hours they’re working. In fact, they very well may be working extra hours to try to stay on track. You need to identify and address the root cause(s) of the problem, not pull them into a conference room and rip them a collective new one. If tasks are being assigned informally (e.g., bugs from prior projects, “small” requests from old team members, etc.), you need to start intercepting, tracking, and prioritizing them. If the team is on track but communicating poorly, well, that’s your fault, and easily fixed by more proactive status reporting. If a project is getting stuck in the unending twilight of “90% done,” you need to stop everything, get the team to enumerate all remaining tasks, re-prioritize, and start tracking progress meticulously and in a highly visible fashion. And if there are clear barriers to productivity in their environment (like, for instance, having a boisterous tele-sales team seated next to the engineers), you need to start fighting to fix the situation.
Commitment. There’s a common belief that engineers should be so passionately committed to the success of their company that they’re willing to sacrifice nights, weekends, personal lives, even families at the altar of their corporate OKRs. Of course it’s never stated so baldly – usually, an executive will talk about “ownership,” “commitment,” and “passion” – all good things, and likely not even meant ironically, or as code for “sucker.” They’re frequently working those hours themselves – because they want to succeed, because it’s been expected of them by their bosses, because they have significant equity (and thus will disproportionately benefit from increased sacrifice), because this is what they’ve been taught is normative. As you rise in the hierarchy, people tend to work more hours, not less, and it’s easy for them to get impatient with people who don’t do the same.
The other piece that gets overlooked in the Google story is the value of hard work. When reporters write about Google, they write about it as if it was inevitable. The actual experience was more like, ‘Could you work 130 hours in a week?’ The answer is yes, if you’re strategic about when you sleep, when you shower, and how often you go to the bathroom. The nap rooms at Google were there because it was safer to stay in the office than walk to your car at 3 a.m. For my first five years, I did at least one all-nighter a week, except when I was on vacation — and the vacations were few and far between.
– Yahoo’s Marissa Mayer on Selling a Company While Trying to Turn It Around
Some software developers place a high emphasis on project heroics, thinking that certain kinds of heroics can be beneficial (Bach 1995). But I think that emphasizing heroics in any form usually does more harm than good. In the case study, mid-level management placed a higher premium on can-do attitudes than on steady and consistent progress and meaningful progress reporting. The result was a pattern of scheduling brinkmanship in which impending schedule slips weren’t detected, acknowledged, or reported up the management chain until the last minute. A small development team and its immediate management held an entire company hostage because they wouldn’t admit that they were having trouble meeting their schedule.
– Steve McConnell, Rapid Development, “Classic Mistakes: Heroics”
Work is a marathon, not a sprint, and “heroics-based development” isn’t an effective long-term strategy for high output. Long hours can be a useful tool to achieve meaningful short term objectives (e.g., working over the weekend to meet a Monday deadline), but will generally be followed by some compensatory underwork. Likewise, long-term overtime is generally matched by an almost equivalent reduction in productivity. You may think your team is getting more done because they’re working 80 hour weeks, but over time they’ll just start shifting “home” activities into “work” time – internet errands, social media, videos, gaming, etc. – and the actual time spent completing tasks will be more fragmented, less focused, and less likely to involve flow.
The way to get more out of your team is to remove barriers to productivity – automate away common tasks, reduce distractions, provide performant equipment, retire technical debt – not to create an abusive workplace environment. How many executives demand extra hours but won’t shell out the money for bigger monitors or dev machine upgrades? Why is it ok to demand personal sacrifice, but impossible to change office layouts to avoid common productivity anti-patterns? It’s your job to be the adult in the room, figure out actual solutions to productivity issues, and fight for them.
What to do
The point of all of this is that there are two ways that managers typically try to extract value from workers. The first way is to cajole, coerce, bully, or trick people into working more hours for the same pay.
For all the talk about “working smarter,” there is a widespread sense that what real-world management is all about is getting people to work harder and longer, largely at the expense of their personal lives. Managers are forever tooting their horns about the quantity of overtime their people put in, and the tricks one can use to get even more out of them.
– DeMarco, Lister, Peopleware: Productive Projects and Teams, p 13
This can work for a while, as long as you don’t mind being a terrible person and creating a living hell for your team. Far better is to get more work from the same number of hours through increased productivity. This is typically done by empowering your team, clearing the way, communicating, mentoring, etc. It should come as no surprise that the first method, being easier and requiring less experience, is by far the more common approach.
You aren’t going to change the faith of a true believer through reasoned argumentation. It’s too easy for them to see the short term gains, too hard to measure the long-term costs. But you can try to limit the damage. When the call comes in (as it inevitably will), focus on the above three categories. If your team is demonstrably under-working, dig in and understand why – it’s almost certainly a symptom of a larger problem, and that’s what you need to fix. If the problem is output or productivity, identify the root cause. And if the problem is executive immaturity, push them to identify an actionable issue (low productivity, output, etc.) instead of perseverating on vague concerns around hours and commitment.
Dan Dreams of Coding 