About a year ago, Tighten officially implemented a "20% time" policy for its developers. This means that, on any given week, we only bill our clients for 32 hours of developer work; for the other 8 hours, developers can work on whatever projects they’d like to (as long as they can readily come up with an explanation of how it benefits the company in some way.)

In this last year, our team has accomplished a lot using that time. The majority of the posts on Tighten’s blog were written at least in part during developers' 20% days, and most of the maintenance and innovation on our open-source projects happens during that time as well. Often, we’ll take those days to work through tutorials on new frameworks, especially if we know we have a client project coming up with a technology we’re not familiar with, or to experiment with new ideas that may not ever lead anywhere so that we’re not doing it on a client’s dime.

It also means that Fridays at the Tighten (virtual) office are ridiculously relaxed.

Our guidelines for 20% time are simple:

• What you’re working on has to benefit Tighten in some way; you can’t spend that time learning French or watching TV
• The first 32 hours of your week need to go to client work; if you only work a 4-day week because of a sick day, holiday, etc., you don’t get 20% time
• At the beginning of your 20% day, you have to summarize in a dedicated Slack channel what you hope to accomplish that day
• Anything you produce during 20% time belongs to Tighten

But reducing the number of hours your developers are working on client projects or company products by a full 1/5th can be an intimidating thought for managers. Here are some reasons that you may want to consider experimenting with a policy like this:

The Case for 20% Time

Have more well-rounded developers

We work in an industry that changes fast, and it can be difficult to keep up with new technologies. By giving your developers 20% time to explore the things that interest them, you make it that much easier for them to stay up-to-date with the latest frameworks and best practices.

My React knowledge — and later, my tutorial series about it — came directly from being given the flexibility to explore it in my 20% time, and now, most of the client projects I’m assigned to involve React in some way.

Even as I write this (on a 20% day), several of our developers are using their time to work their way through Adam Wathan’s fantastic Test-Driven Laravel course. Even though we do a lot of testing at Tighten, we’re excited to pick up some new tricks that we can put into practice on client work or our own products.

Reduce stress by increasing work-life balance

Of course, if you don’t give your developers 20% time, many of them will pursue learning new skills — or open-source contributions, or writing — in their own after-work hours. But it can be hard to make a choice between professional development and catching up on Netflix and sleep, especially if you have other responsibilities like a family and/or pets.

The other stress-reducing major benefit is sustainability. Even if the project you spent the first four days of your week working on was incredibly tedious or draining, you know that, after your 32 billable hours, that you’ll get the chance to relax and unwind by working on something fun that you’re passionate about. Fridays often don’t even feel like work days when I know I’m going to get to spend my day writing about something that excites me.

Increase personal and company profile

As I mentioned before, a big part of the reason for much of the content on our blog — as well as the high number of contributors from our team — is our 20% time. Over the last year, this has proven to be an invaluable business development tool for Tighten. We have attracted new clients through displaying our expertise on technical topics, potential hires through posts on company culture, and Twitter followers through some of our more casual and fun posts.

It's not hard for most companies to see the benefits of having an active blog and strong open-source project portfolio, but if you're not giving your developers the time to contribute, they may not see a compelling reason to spend their personal time working on things that only benefit the company. However, give them some extra time on your dime to use their skills to build cool things for you, and many of them will get so passionate about what they're doing that they'll gladly put in some of their own time to see it through.

Developer happiness and retention

20% time is a major benefit to offer your developers. The turnover rate at Tighten is extremely low, and 20% time is a huge part of Matt and Dan’s experiment in making a great company culture. While it’s not the cheapest benefit you can offer — it’s not as low-effort as, say, simply picking up a ping-pong table for the office — it can arguably have some of the greatest rewards, if used responsibly by members of your team. Just ask Google, a major proponent of this practice; many of its most popular products — Gmail, AdSense, Google News, and Google Talk among them — were projects started by its engineers during their 20% time.

However, 20% time may not be a great fit for every team. Before you think about implementing a policy like this, there are a few questions you need to ask yourself.

Is 20% time right for my company?

Am I able to place trust in my employees to use this time wisely?

It's important to note that the question is not whether you should place trust in your employees; if you can't trust the people working for you to be productive on company time, then it might be time to make some tough personnel decisions.

But if you're going to give your developers 20% time, you need to be able to get out of their way. While there is nothing wrong with promoting accountability, such as implementing a Slack channel like we have at Tighten, 20% time is ultimately about experimentation. Often, at the end of the day, we don't have concrete deliverables; we may have the beginnings of a new skillset or 10% of an open-source plugin, but 8 hours is not a lot of time for major accomplishments.

Do my developers want it?

The decision to give your team 20% time is not one that should be made in isolation. It's important to talk to your developers first to get a sense of how they would use that time. Do they have a desire to get more involved in the blogging or open-source world? Some people are totally happy keeping their head down and just plugging away at client work when they're on the clock; there is a lot of responsibility and discipline involved in using 20% time productively. It's not for everyone.

Does it make sense with the current developer workload?

20% time is great for companies that generally stick to a 40-hour-per-week schedule. However, if your developers are already putting in overtime to get their work done, adding the burden of 20% time will only cause them to work longer hours and burn out faster. At Tighten, when we hit the occasional week or two of crunch time, we'll often forego 20% days to make sure we're hitting deadlines, but this is pretty rare; if your team is consistently putting in 50- or 60-hour weeks, it would make more sense to put some resources toward a more managable and sustainable schedule for your devs than pushing them to contribute to your company blog or open-source.

Ultimately, having a culture that promotes curiosity and experimentation is not easy or cheap, but it can go a long way toward making your developers happier, more productive, and more well-rounded employees.