How much work should you do? If you manage a team, how much work should each of your direct reports do?
It’s a simple question, but how you answer it can have a profound impact on your company and culture.
Really, there are two ways to view how much work you should do:
Work as long or as short as you have to, so long as you get your work done. What this means is that a manager of a team using this philosophy will, to a greater or lesser extent:
This has an innate appeal to developers. Those who favor this model dream of completing a 3-week project in 2 days, then skipping out for a free vacation. We all like to think we’re smarter than the average bear, so it’s an attractive view.
It also incentivizes smart working over hard working. It pays off free time to developers who find more efficient or automated ways of doing a given task.
It’s an especially good way of accommodating a mix of developer skills: good devs work fast, mediocre developers work a bit longer, and you get the same amount of work out of each.
This system relies heavily on managers being able to correctly size what “your work” is. If they overestimate, you’re stuck working late.
In theory, if they underestimate, you go home early. In practice, your manager has a perverse incentive to just add more work each cycle if you keep finishing ahead of schedule.
Naturally, this leads to crunch time. Because it’s impossible to really predict how long a given project will take, you’ll always end up with some heavy weeks and some light weeks. Managers, when they see a light week, will increase work expectations. As they say, “the reward for fast work is more work.” Now that your “light” weeks fill the entire week, normal and heavy weeks run over and take crunch time to complete.
Set a time limit– say 40 hours a week– and get as much done as you can in that period. When you hit the end of that period, you stop working and go home. Practically, this means that your manager will:
This is good for work-life balance: you have a predictable schedule and can plan your life around it.
It also lets your company set clear expectations up front for the time commitment you expect of your employees. Working much longer hours than expected is a common reason I hear for people leaving their jobs (in SF startup land, anyway).
This philosophy works especially well where a developer’s work is less narrowly circumscribed. For example, at a startup, it’s not uncommon for early devs to be working on pretty much everything. Since there’s always more work to do, working “until your work is done” isn’t even particularly meaningful.
As a corollary, the “fixed period” work model lends itself well to self-driven teams. If you have devs that need to be externally motivated, you’ll find people just filling their chairs for X hours a week. But if you have self-motivated people, you’ll find that they always have something productive to do, and sometimes you have to actively tell them to go home and stop working!
Of course, crunch time may still come eventually– usually as the result of an external deadline.
And of course, if you want to be able to evaluate your team, you’ll need to find a way to accurately measure the efficiency of each developer. Since this is an open problem in software engineering management, I wish you the best of luck with it! The more you can simply trust that your developers are working as hard as they can, the easier this strategy is.
And as the opposite of the “finish your work model”, this way of thinking doesn’t automatically reward smart work. If a developer just has to get in their X hours per week, “slog through this menial task” becomes a viable tactic. Managers have to manually reward clever efficiency over mere hard work.
Finally, the “fixed-period” model has the problem that mediocre workers simply get less done than good workers, since they can’t work extra hours to make up the difference. There’s no way around this, short of hiring all equally-skilled developers.
Many companies choose some sort of hybrid. This usually means “You should work 40 hours, but also work more if we decide we want this deadline met.” This means you work 40 hours every week, except the weeks you work 70 hours. It sacrifices both the reliability of the “fixed period” model and the flexibility of the “finish your work” model.
I’d strongly argue for picking one model to embrace as much as you can.
The “finish your work” model seems best for larger companies where the work is more consistent and easier to predict. It also thrives in environments with a solid group of well-tested managers who have been or will be with their team for many years.
The “fixed period” model works better for small companies where the work changes rapidly, and so is hard to predict. It’s also an excellent tool for preventing overwork and burnout, which are common in those environments. I’ve used 40 hours as an example, but it’s the same for 50, 60, or 70 hours. Reliable long hours tend to be easier to take than unreliable medium hours.
It’s also a good system for when you don’t have many managers and you can trust your developers to be as productive as possible without someone looking over their shoulder.
Neither is right for everyone, but you should make the choice consciously.