How does one effectively implement the 80/20 rule for developer time?

Question

I am a developer at a bank where an 80/20 rule is implemented. 80% of the time you work on your assigned project and 20% you work on something that interests you. However, I'm not really sure how to do that. I'm hoping there are others out there who can provide me with advice on how to.

My problem is that when I really get 'in the zone', all I can think about is the task at hand. If this is a 20%'er, the last thing I want to do is stop and go, lose momentum and go back to work on my main project.

Am I suppose to work 4 days on something and 1 day on something else? or 4 weeks and 1 week?

I know this depends on the company, but I'm hoping to get a feel for how this is done industry wide.

Answer 1

Split all your tasks in sub-tasks (the "80%" tasks as well as the "20% tasks") and write them down. Each tasks should be small enough to be done in a few hours at most, and big enough that you can get into "the zone" for it (if it is a task needing your concentration in that way). Then, choose an order to work on those tasks fulfilling the 80/20 rule per week or per month, whatever will be appropriate in your company.

Answer 2

I think if the 20% is company policy, and you get your main projects done, the boss doesn't really care where you spend those 20%. I would try to not splinter up your time too much, at least one day working consecutively on something. And when you get in the zone, just spend a day or two more and compensate later by working more on your main projects.

Answer 3

My company although not implementing a 80/20 rule as such encourages us to consistently keep up-to date with the latest technology, read other blogs and posts such as programmers etc and basically make sure we are keeping our personal development and interests up-to date.

To achieve this they didn't specify an exact amount of time, but made sure that we work on a project and task deadline rather than a by the hour workload. This has meant that we consistently talk with our immediate manager to ensure the tasks assigned to us or we take on are manageable and allow us some time outside of the normal to take for ourselves and refresh our mind and interests. If we are struggling we talk about it to find out why i.e. skill set limitation, too much work, unrealistic deadlines etc

We do keep a rough track of our times spent for billing purposes but this is to the hour on an entire day basis so we are not expected to record what we have done during every minute of the day.

Each of us in the team manages their time themselves so it's up-to them to determine how they do this. Some members of the team work hard at the begging of the week to get their tasks done and any time left over they relax into their own interests. Others like me tend to mix this in during the week as I quite often hit road blocks in my project / task. So at this point I jump over to something else which is quite often my own interest. However as we are task/project driven I still have to make sure I get the job done so it is my responsibility to make sure I don't use all my time on personal tasks at the detriment of the team.

This has in the past lead to some team members rushing their tasks and producing undesirable results. To help with this we introduced periodic peer reviews and also encourage everyone to read other developers code check ins. We encourage an open discussion forum where everyone is free to voice their opinion albeit in a respectful manner.

In the end it came down to a bit of trust from the powers that be, taking ownership by the grunts to ensure the work is done and a good manager in the middle to keep the ship running.

Answer 4

If I had something like that (I wish) I would be inclined to do it like this:

1. Talk about this with your boss and make sure he/she agrees that it will be the case.

2. Be very clear to the other people that you work with that when working on assigned projects they are free to interrupt/talk/ask you stuff. But when you are working on your R&D stuff, they cannot bug you will normal work stuff.

3. I would use Monday-Thursday for work and Friday for R&D. That way, you have a defined time of the week and get a less stressed wind down to the weekend.

Answer 5

The way I see it you have a two options as long as you have a legitimate company policy that allows you your 20%. Make sure that you get your plan approved by your manager.

1. Block out 2 hours of each 8 hour day on your calendar for research time
2. Spend one day a week on research and the other four focusing on your main project

As far as what you are going to research/learn take the time to create a learning plan and set goals. Talk to your manager and see if he/she has any suggestions on things to focus on. Then use Doc Browns suggestion to break your study time into regular tasks. Think about blogging what you are learning.

Whatever you choose to do make sure that you have a plan and document what you are doing so that you can show your employer. Sitting and surfing the web and reading random articles is great and you can learn a lot doing it but you will have nothing to show for it. Tracking the articles you are reading helps with that.

Answer 6

I think the key here isn't to focus on the 80% / 20% as much as focus on making sure you are learning and pushing yourself with new technologies. If you do this already with the stuff you work on daily, great! If not, then make sure to either mix in new stuff or set aside some time right after you complete a deliverable and do it then.

I realize some new technologies don't lend themselves to stable development (CTPs, Beta, etc.) and I'm not advocating that you mix that stuff into your normal work. Unless that's the type of edge your company rides.