There are a number of thoughts on the Google mandate that all developers spend 20% of their time on self-directed projects. Allow me to drop my own 3 cents into that fountain.
Consider any technology project at any medium to large sized company. 50% to 70% of the total project time is spent on planning and definition. Another 10 to 15% goes to QA.
So you’re looking at best case of 40%, worst case 15% of the project timeline being actual development time.
I’ve actually seen the 15% case on occassion. It is a truly ugly beast.
In the regular world a business or marketing person comes up with an idea, creates a big thick Marketing Requirements Document, hands it off to product folks, who create a lovelier, thicker Product Requirements Document, who hand it off to the architects, who copy and paste stuff around and attempt to convince people they’re doing something useful to finally arrive at … the Technical Requirements Document.
After much negotiation and back and forth on the features and what is doable, the doc is finally handed off to the code monkeys, who are now clearly behind the 8 ball because 60% of the project timeline is already eaten up. And we can’t short-change QA, because we are Committed to Quality. Indeed.
Somewhere around the 70-80% mark of the project timeline, we finally have something we can see. Ah, that’s what the product looks like. Wow, that’s an ugly wart there. And this feature that we decided not to do, boy, we really need that one. The product and business guys haven’t been sitting on their hands either; they have a list of stuff they’d like to creep in. Yup, we’re in good shape to make this schedule. If the project doesn’t get cancelled, now that people actually see what it’s all about.
In the Google world, you’ve got a bunch of smart overachievers with a mandate to be creative and come up with the next big thing, and company allocated time to do it in. There’s a great deal of competitive pressure, because that other guy in the next aisle is doing something neat and I still haven’t thought of anything…
So these guys go home and think about it. What should I do? And one day in the shower, the idea hits!
Point is, getting the idea costs the company nothing. This is a high quality idea from a high quality person, someone who might have gone off it do it at her own startup, but Google got it for free.
Now, the 60% to get at the TRD so we can get the monkeys revved up and… Oh wait, none of that. The guy with the idea is the monkey! And the monkey actually cares about the idea. It’s his idea. It’s his baby. Her baby. Politically correct genderless baby. Whatever. We just jumped ahead of the rest of the world by 60%!
But it’s not over yet. Monkey man (/woman/person) cranks thru and comes up with … a prototype. There it is. Now we can see it. We can touch it.
Fundamentally, it’s easier to make a decision about the value of an application when you can see it and touch it. It’s also a better informed decision that you make. Think about Google News. It wouldn’t be an exciting idea till you actually saw it in action. Would you have gotten excited about yet another news aggregator?
Ok, back to the prototype:
Boy, what a terrible idea! It reeks. We lost 20% of 1 techie’s productivity for X amount of time.
Boy, what a great idea! It’s a winner! We just jumped ahead 60% (ok, say 40%, because those wonderful product people do have to get involved eventually). That’s total project time. We jumped ahead of everybody else an obscene amount of time.
Remember, we’re doing this with every developer. Some percentage of the ideas are going to be winners. A bigger or smaller percentage than the Other World method where a business or marketing person comes up with the idea? I’d venture to say, given the right set of developers, it’ll be comparable or better. But it actually doesn’t have to be even close to as good for the whole thing to work. We’re running mini experiements all over the place with every developer. If 1 in 10 works, we’re still ahead of the game.
If you don’t like the numbers I used, use your own. Do your own mini calculation, and you’ll be suprised to find this still works. You just have to believe the monkeys are smart, that they care, that they’re capable, and give them time and facility to help you.
So, that’s my take. It’s all about short-cutting the product definition cycle, getting product out faster, going straight to working prototype, and making intelligent decisions about what to launch. It’s avoiding decision by committee. It’s a brilliant tool for accelerating value delivered to the company. It also keeps the monkeys happy and excited, but that’s a side benefit. These are all good things. If you have monkeys, you should try it.