Do you have "Slack" time? [closed]

Question

The CodePlex team has a Slack time policy, and it's worked out very well for them.

• Jim Newkirk and myself used it to work on the xUnit.net project.
• Jonathan Wanagel used it to work on SvnBridge.
• Scott Densmore and myself used it to work on an ObjectBuilder 2.0 prototype.

For others, it was a great time to explore things that were technically not on the schedule, but could eventually end up being of great use to the rest of the team. I'm so convinced of the value of this that if I'm ever running a team again, I'm going to make it part of the team culture.

Have you had a formalized Slack policy on your team? How did it work out?

Edited: I just realized I didn't define Slack. For those who haven't read the book, Slack is what Google's "20% time" is: you're given some slice of your day/week/month/year on which to work on things that are not necessarily directly related to your day-to-day job, but might have an indirect benefit (obviously if you work on stuff that's totally not useful for your job or your company, your manager probably won't think very well of the way you spent the time :-p).

Daric

Answer 1

I just want to mention Google's policy on the subject.
20% of the day should be used for private projects and research.

I think it is time for managers to face the fact that most good developers are a bit lazy. If they weren't, we wouldn't have concepts like code reuse.
If this laziness can be focused into a creative force, and the developers can read up on technical issues and experiment with architecture and language features, I am certain that the end result will be better code and a more satisfied developer.

So, if you are a manager: Let your developers slack of now and then. Encourage them to hold small seminars with the team to discuss new ways of doing stuff.

If you are a developer: Read, learn and love your craft. You have one of the best jobs in the world, as long as you are willing to put some time into learning the best ways to do your job.

Hertfordshire

Is code reuse really about being lazy? – Kwangchowan

Answer 2

I am currently a full time freelancer working for a single client. If I want to get a full 40 hours of pay, then every minute I spend coding needs to be accounted for on the approved project plan. Or at least it has to go towards some sort of realistic maintenance task. I guess you could say this is one of the disadvantages of contracting... there's really no room for slack or being idle. You just have to keep going and going on the task at hand. It can be quite draining, but then again I kinda like how it keeps me accountable. And of course the pay is a bit better than usual.

That said, I would love to have slack time available for working on pet projects, but no client would ever agree to pay for that.

Anyway, I just thought I'd point out how this exemplifies some of the big differences between freelancing and full time employment.

Osvaldooswal

Answer 3

I've also never worked anywhere where there was a formal policy but I have always found was to squeeze in a little R&D/tool-building time on the side. Often times I will get productivity gains out of that which will allow me even more 'slack' time.

Siva

Answer 4

I've never worked anywhere that had a formalized policy, but practically every manager I've ever had has allowed me to spend some time on things that weren't directly related to the current project or fighting a fire.

I think the key is to talk about the things you'd like to try. Most managers want their teams to do something cool, something extraordinary, so if you can convince them that you might deliver something, you might get the chance. Or they might let you do it just to keep you happy.

Now that I'm a contractor rather than an employee, I don't get paid to do fun stuff, but I generally only work 30-35 hours per week, so I still have time to learn and to play.

Diction

Answer 5

We have slack time and we try to schedule them between releases. Once a release is out, we ask our developers to spend 60% of the day fixing bugs and then the other 40% for slack time. We have policies on what you can use the slack time for though. Then when a release creeps up again, we ask all the developers to spend all day on implementing features or fixing bugs for that release.

The policy lets the developer use the slack time for training, creating something new that the company could use, or just creating tools within the company to make things easier for ourselves. It has worked well for us. We think it is an awesome benefit.

Argo

Answer 6

We don't have a formal policy in my team - mostly because there is just so much work to do that justifying it would be hard. Which is pretty ironic.

I've started doing some formal things in the guise of "Development Meetings" in order to at least inject the essence of this into the team. An example of this is a development project that is intended to both teach new technologies and produce a cool app at the end of it.

It's early days, we'll see how it goes.

Dogged