A lot of bosses and companies try to squeeze every ounce of productivity out of their employees that they can. Some of them even try to guilt, coerce, or demand that they work overtime on a regular basis.

The irony of this is, not only are they not getting more done, trying to force total efficiency or extra work is actually setting them up for failure and, possibly, for catastrophe. In addition, aiming for 100% utilization is impossible anyway.

The alternative to this is to build slack time into your schedule. I realize that this is heretical to a lot of people (including several former bosses of mine), but it’s an incredibly important part of being less reactive and more proactive (or, put another way, being less tactical and instead being more strategic).

So, what the heck is slack time anyway?

Slack time isn’t just sitting there, staring off into space or spinning around in your office chair (despite what my former bosses have believed). It’s time when you do things other than work on features for your project, and it can take many forms. I’ll go over just a few of them here.

Professional Development – You should be setting aside some time every week for your people to learn new things. Whether it’s watching a video, playing with some new tech, or a number of other things. Learning is part of their job and this needs to be realized and acted upon.

Strategic Planning – Both you and your people need to take time to look at the bigger picture of the things you’re working on. Among other things, you need to stop and think about why you’re taking the actions that you are and see if there’s a better way to reach your business goals.

I can hear several of my former bosses start to claim that it’s their job to think strategically and the developer’s job to do as they’re told. I’d like to take a moment to tell them how wrong they are and point out the damage that they did to the projects by taking this stance.

Paying Down Technical Debt – Technical debt is sort of like monetary debt. If you don’t pay it down, the interest it generates will kill your project by making it harder to make changes to the code over time. That “really quick fix” that you put into place to fix a production bug or “easy feature” that you shoehorned into a class that wasn’t meant to contain it makes it harder to modify the code. If you do it often enough, it makes it almost impossible to modify anything without breaking things.

Ideally, your team should be doing some work to pay down technical debt any time they work in a section of codebase, but if they feel pressured to always do more, this often doesn’t happen. Sometimes you just have to set time aside specifically for paying down some of the debt.

Improving The Working Environment – No, I’m not talking about upgrading the chairs in your office (though if you have the budget and, for some reason still have people in a physical office, go for it. It’s worth every penny).

Spend time to improve the tooling that you use as a team. Don’t have a CI/CD pipeline, build one out. Don’t have monitoring in place, start working on it. Don’t have your logs aggregated so that they’re easily searchable, allowing you to spot trends or find problems without logging onto a physical or virtual machine (yes, there are still companies that use physical hardware and standalone style VMs), look into ways to get that in place.

In short, make the lives of your people easier. The less time they have to spend fighting the tools and processes that are holding them back, the more value they’ll be able to deliver to your business.

I can hear you going “you know, some of that sounds really great, but it sounds like it’s going to take a lot of time away from actually doing work.” The truth is that each of the things that I’ve listed is work, and they are all vitally important to your business being able to continue functioning. Unless your business is a quarter away from insolvency, then it behooves you to do these things and that requires that you stop trying to be “100% productive.”

Also, remember when I said that not having slack time can be catastrophic? If you work your people into the ground as a feature factory, when (not if, when) you have an emergency, you’re going to be dead in the water because your people are going to be so fried that they can’t think straight. The above items can even help prevent catastrophic emergencies because you might be able to catch them before they happen.

So, just how much of your team’s time should be “slack”? In my experience, about 25%

Yes, I realize that it sounds like a lot, but realize that there have been studies that show people only have about 4-6 hours of productive work in them per day anyway, so they’re already taking slack time. The only thing is that they’re not using it well and are, instead, pretending to work so you’ll get off of their backs.

It won’t happen every single week because sometimes emergencies do happen and sometimes there is a make or break deadline, but those times should be rare.

A couple of hours (at least) a week should be set aside for your team’s professional development. The rest of the “slack” time should be split between the high-value work of the other items above (or similar).

Yes, that’s a departure from the Taylorism based management practices you were taught or indoctrinated with, but Taylorism doesn’t work in an economy based on creativity. It was designed for assembly line style work, and honestly, there were better approaches there too.