4 ms·

20% time is the idea that it's OK to put "only" 32 hours (or, in practice, 25-30) on your assigned project, but there is certainly not an 8-hour maximum on the

20% time is the idea that it's OK to put "only" 32 hours (or, in practice, 25-30) on your assigned project, but there is certainly not an 8-hour maximum on the side project. If you want a promotion, you'll have to put in more time than 25-32 hpw; but you won't get in trouble at that effort level. Of course, this is true in most companies-- a 25-hour effort on your assigned work is not low enough to get you fired, almost anywhere; it means that you're not outrunning the bear but you're outrunning someone-- but the difference is that you don't have to hide side projects. That makes a pretty substantial difference. It's a good idea, not because the number means anything, but because it means that (under most managers, although there are exceptions) you don't have to deny or hide working on other things ("skunk works") that might prove useful. You can talk about them openly. In companies without 20%T projects, people still do those types of projects, but are afraid to share their work, which means those projects go nowhere. Google doesn't seem to have that problem. If you build a demo and share it, that's encouraged. Google is still better than many companies (yes, I'll say it; it is, if you land in the right place, a great place to work) but an incredible amount depends on your manager. The biggest moral failing of Google probably is how easily a manager can become a SPOF for your career. That's not different from most companies, but any firm that wants to call itself progressive ought to solve that problem. You'd think it would be a first order of business.

auggierose 13y ago
Still, a certain mental makeup is necessary to be able to switch between projects like that. When I work on a project that interests me, I go to bed thinking about it, and in the morning I want to continue where I left it. Often I'll see things clearer after such a sleep break, and then I cannot just switch to another project instead of trying out an idea I had.
- nostrademons 13y ago
  This is a learnable skill, and one that is IMHO very worth learning. I also have a tendency to want to just load a whole problem into my head, Think Real Hard, and then write down the solution as quickly as I can. It's a great strategy, when it works. The problem is that it doesn't scale - it sets a limit on the complexity of problems you can attack directly, and it prevents you from working on more than one problem at once. So what I've found, as I work on more complex problems, is that I really need to adopt all those tactics that back in college I thought were reserved for "lesser" minds. Things like breaking down a problem into chunks and then writing down all the intermediate steps. Adopting a bug database, spreadsheet, or task management software. Thinking about the external impact of a change, and communicating it to other parties. Showing off intermediate demos, and breaking the problem down into a form where intermediate demos are possible. Asking for help from other people. These are absolutely essential if you want to work on anything that takes more than a month, but the nice side effect is that you then get the ability to work on multiple projects for free. All the problem state is externalized, so if you need to work on something else, you can just drop it, switch contexts, and read your own documents or bug queue to figure out where to pick it up.
  - auggierose 13y ago
    I agree that all of these measures help greatly, in particular with bigger problems. Nevertheless, I found that in the end, even when you've broken up a problem into chunks, keeping your focus on these connected chunks for an uninterrupted extended time period is invaluable. Often your realise that you should reorganise the chunk division etc. Of course you also benefit from breaks of looking at the problem, but these breaks tend to occur naturally for me, and are very different from a forced break of having to tend to another project. Or let's put it another way: I don't multitask / switch contexts.

auggierose 13y ago

Still, a certain mental makeup is necessary to be able to switch between projects like that. When I work on a project that interests me, I go to bed thinking about it, and in the morning I want to continue where I left it. Often I'll see things clearer after such a sleep break, and then I cannot just switch to another project instead of trying out an idea I had.

nostrademons 13y ago
This is a learnable skill, and one that is IMHO very worth learning. I also have a tendency to want to just load a whole problem into my head, Think Real Hard, and then write down the solution as quickly as I can. It's a great strategy, when it works. The problem is that it doesn't scale - it sets a limit on the complexity of problems you can attack directly, and it prevents you from working on more than one problem at once. So what I've found, as I work on more complex problems, is that I really need to adopt all those tactics that back in college I thought were reserved for "lesser" minds. Things like breaking down a problem into chunks and then writing down all the intermediate steps. Adopting a bug database, spreadsheet, or task management software. Thinking about the external impact of a change, and communicating it to other parties. Showing off intermediate demos, and breaking the problem down into a form where intermediate demos are possible. Asking for help from other people. These are absolutely essential if you want to work on anything that takes more than a month, but the nice side effect is that you then get the ability to work on multiple projects for free. All the problem state is externalized, so if you need to work on something else, you can just drop it, switch contexts, and read your own documents or bug queue to figure out where to pick it up.
- auggierose 13y ago
  I agree that all of these measures help greatly, in particular with bigger problems. Nevertheless, I found that in the end, even when you've broken up a problem into chunks, keeping your focus on these connected chunks for an uninterrupted extended time period is invaluable. Often your realise that you should reorganise the chunk division etc. Of course you also benefit from breaks of looking at the problem, but these breaks tend to occur naturally for me, and are very different from a forced break of having to tend to another project. Or let's put it another way: I don't multitask / switch contexts.