When to Hit the Gas

In my last post, I alluded to a set of criteria that I use to determine whether or not it is reasonable to ask a team to work significant extra hours—such as going over 45-50 hours in a week or working a weekend at all. What I didn’t do was describe the composition of that criteria.

I typically am looking for three factors to be met; so when I’m determining if it is appropriate to ask for the additional work, I look for:

Is there a defined, specific, goal? This doesn’t mean “finish the project,” as that is the sort of down-the-rabbit-hole trap that ends up dragging teams to an early exit. This means “we have these clearly defined tasks with clearly defined success conditions that must be done.”

Is the goal possible? My criteria used to be 2-items in length, until I was at a job that delighted in giving clearly defined criteria that were clearly impossible. Nobody should be sent on a death march.

Is the duration and severity reasonable? Saying “we have a clear, specific goal of working 80h weeks for no more than 2 months to do these 100 items” might be sufficiently specific and plausible, but the duration and severity virtually guarantee that quality is going to be thrown out entirely.

These are not the only factors that I consider—length of time since last the developers involved have been asked to do this, how did we get in this predicament in the first place, is this a reasonable thing to ask to get us out of the predicament; these are all also considerations to varying degrees—but the above are the primary drivers of my decision making.

In practical terms, this is handled as a conversation. By way of example, on projects for my current employer, working considerable extra time was brought up in two distinct situations on two separate occasions. In both instances, I sat with our senior management team and walked through the above thought exercise.

In one instance, it was determined that while the scope of work was relatively well defined and possible, the duration of the overwork would be such that it was very likely to destroy quality. It was also likely to have a significant impact on the development team as a whole. In that instance, we decided together that it wasn’t worth the risk, and found a plan that would yield more reliable results.

In the other instance, while the same risks were very much present, the volume of work was more reasonable and we all felt comfortable in using over-work as a strategy.

In both cases, working together first with my management team then with my development team was an essential piece of the decision making process. It has been my experience that this criteria has both served as a gatekeeper for preventing burnout and low quality due to overwork, but it has also served as a educational opportunity for all involved every time it has come up.