Refactor Fridays

The topic of slack time came up recently with some colleagues and I described how I’d introduced something called “Refactor Fridays” on a client engagement. While most people have heard about Google’s 20% time or Atlassian’s 20% time experiment, understanding and developing a slack time program isn’t easy. This post looks at some of the theory behind slack time and offers some guidelines on implementing slack time in your team.

What is Slack?

In a traditional, organizational economics, sense, slack is defined as any excess capacity of an organization’s resources. This could be a machine running at only 75% capacity or extra capital not being put to use. Regardless of the context, slack is some amount of uncommitted resources. Historically, slack was viewed as a wasted opportunity, but this view is changing. Instead of being seen only as a waste of available resources, slack time can be viewed as a cushion against sudden demand spikes or as an opportunity for grassroots innovation.

What Slack Isn’t?

A common way to view slack is as padding when determining timelines. If a developer believes a task will take 10 hours but she says it will take 20, the padding isn’t slack since the developer is still committed for the 20 hours regardless of how long the task takes. Slack is a supply of uncommitted resources, not conservative resources.

Implementation

My client’s situation wasn’t typical for organizations looking to adopt a slack time policy. The startup team was (and still is) distributed, feature velocity was extremely demanding and the competitive landscape was (and still is) changing rapidly. These factors combined to introduce technical debt, significant stress within the engineering team and little product innovation outside of immediate customer requests. The goal dedicated slack time was to address each of these issues.

The slack time program started by defining what tasks would fall under the program. We specifically targeted addressing technical debt as the primary goal and non-essential feature development as secondary. Non-essential features might include adding JMX functionality to core components or dropping in some AJAX to improve the user experience. With an agenda in place, the next component was some way to verify what was being done to ensure the company was getting value by allowing developers free reign on Fridays.

“Look at What I Made!”

Proving the value was always the easiest part. The projects the team undertook on their 20% time were interesting, making Show & Tell a common occurrence. When people are interested in what they’re working on, they want to share it. By getting immediate feedback, the idea can be shaped by emerging business requirements. However, we were a small team and justifying effort was easy. Your organization may require more detailed reporting requirements.

Dedicating slack time for your developers to work on personal projects may not appear to be a good use of time and money. Every project has technical debt, and every developer has an idea on how to improve the current product. By allowing your team to experiment in a structured way, you can clear some of your debt and support incremental innovation in your application. Most importantly, your team will appreciate the trust you’ve put in them.

Have you implemented some form of structured slack time for your engineering team? If so, how did it work out? Let me know in the comments.

Copyright © Nick Heudecker

Built on Notes Blog Core
Powered by WordPress