View source for 12%-time

'''12%-time''' is an innovation program wherein employees dedicate approximately 12% of their work week (typically four hours out of a 32-hour workweek) to pursue projects of personal interest that could potentially benefit the company. This concept is adapted from [https://en.wikipedia.org/wiki/Side_project_time Google's 20% time concept]. 

== Goals ==
12%-time creates structured slack in employees' schedules. This has two primary goals: 
# force us to create slack in project schedules, that can be consumed when time runs over. 
# allow for more experimentation and creativity that might not naturally come up in projects. 

Slack in projects is important. A fully utilized project (or team) is [https://blog.danslimmon.com/2016/08/26/the-most-important-thing-to-understand-about-queues/ virtually guaranteed to fail to meet its deadlines]: any small delay during a project would cause you to violate the deadline. One of the ways we ensure slack is included in our workweek, is by booking ''up to 4 hours'' every week of 12%-time. Yes, that's actually 12,5% of your 32-hour workweek, but the shorter name has stuck. 

Secondly, 12%-time allows for experimentation and learning outside our regular projects. The availability of work shapes projects. It might benefit Delft Solutions to have you know React, but a React-based project might not come up for months. 12%-time allows for learning React on your terms. Or we might want a new plugin to calculate vacation hours in Kimai, but can't create a project for that. You could build it in 12%-time. 12%-time allows for exploration of new ideas, innovation outside of your daily responsibilities, skill development, and potential development of new products or features. 

== Doing 12%-time at Delft Solutions ==
# What to work on:
## Choose your own topics & projects. No one assigns you 12% work. While others might have suggestions, you decide how to allocate time. 
## You can work on things over multiple weeks, or choose a different topic every week for variation.
## What you work on, should be "work-related". We take a broad view of that requirement; it doesn't have to be directly related to your job. Learning a new programming language, trying a new technology, building a badge reader for the office door, learning bookkeeping or accounting, making a meeting timer, etc. are all great examples of using 12%-time. On the contrary, underwater basket weaving, sleeping, and remodelling your bathroom are not. 
# How to budget & plan for 12%-time:
## Limit your 12%-time to 4 hours per week over a long-term average. It's okay to spend more or less time on 12%-time per week, it doesn't have to be exactly 4 hours. Try to stick closely to four hours per week though; having you do 0-0-0-16 hours in a month would defeat goal 1 of having slack every week. As a general rule, do not go over 5 hours in a particular week.
## Do not catch-up on 'missed' 12%-time. If a week was quite busy, the work consumes the 12%-time as a buffer, as it was intended. The next week, just do 4 hours rather than 8 hours on 12%-time. If you worked 5 hours on 12%-time this week, try doing 3 hours next week. 
## If you miss 12%-time multiple weeks in a row, bring it up as a topic for the weekly retrospective. It indicates that the workload is not correctly distributed throughout the team. If the whole team is not getting to 12%-time multiple weeks in a row, that's a strong indicator that we're overloaded.
## Plan your 12%-time towards the end of the workweek, probably Thursdays and Fridays, as it becomes clear that work objectives will be delivered on time for this week. Missing work objectives or deadlines while still working 12%-time in a particular week is a major cause for concern and should never happen. The 12%-time is a buffer, not a dedicated project. 
# Demo your work during the Retrospective
## Before the weekly retrospective, you can propose an agenda item for showing the results of your 12%-time. 
## Prepare beforehand to discuss your 12%-time in the past week. In about 3-4 minutes, you should share: 
### anything new you've built
### any learnings you had. Never assume that everyone else already knows what you've learned this week. That's almost never the case. 
### You can talk about your process or what you did, but this should not be an exhaustive summary of your time spent. Focus on the results and outcomes.