Software Project Management at Google
Recently I ran across a good article on project management. See if the author’s description of typical project management sounds familiar:
- Hire a bunch of engineers, then hire more.
- Dream up a project.
- Set a date for when they want it launched.
- Put some engineers on it.
- Whip them until they’re either dead or it’s launched. Or both.
- Throw a cheap, pathetic little party, maybe. This step is optional.
- Then start over.
- There are managers, sort of, but most of them code at least half-time, making them more like tech leads.
- Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.
- Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.
- Developers are strongly encouraged to spend 20% of their time (and I mean their M-F, 8-5 time, not weekends or personal time) working on whatever they want, as long as it’s not their main project.
- There aren’t very many meetings.
- It’s quiet. Engineers are quietly focused on their work, as individuals or sometimes in little groups or 2 to 5.
- There aren’t Gantt charts or date-task-owner spreadsheets or any other visible project-management artifacts in evidence, not that I’ve ever seen.
- Even during the relatively rare crunch periods, people still go get lunch and dinner, and they don’t work insane hours unless they want to.
It’s a pretty interesting - though quite lengthy - article, which you can find here (note that the author does swear with some proficiency, so if you’re sensitive to such things, use your best judgment before deciding to read it).