Justifying your dream job

One responder to the article I wrote on "My dream job", a manager at a large software company, called it "selfish". We communicated back and forth, and the exchange was interesting so I want to share some of it. I've taken some liberties with paraphrasing, but this is the gist of our conversation.

"Where's the benefit to the employer?", he wanted to know first.

I thought the benefits would be self-evident but perhaps not. They includeWhat's good for the employee is good for the employer. satisfaction, loyalty, self-improvement, quality, encouragement, productivity, respect, honesty, collaboration, quickness, flexibility, camaraderie, and pride. It boils down to this: what's good for the employee is good for the employer. I cited Google as an example of a company that embraced some of these ideals successfully.

"Do you really believe Google allows their employees 20% of their time for doing whatever they want?", he asked. I've talked to several Google employees and it seems to be true (see here, here, and here). Pursuing your own projects isn't just "allowed", it's encouraged as part of your job. "But what if they spend that time," he worried, "on things unrelated to their main project?". That's kind of the point, I replied. Sometimes the best ideas come from unexpected places.

"Suppose one of them didn't buy into the idea of spending times researching other things," he countered, "and they used all their time on their main project. Wouldn't they have an unfair advantage?"  His thinking was that if people saw their colleagues focusing only on their assigned jobs and getting ahead, then everybody would want to do that; nobody would want to "waste" 20%. I argued this wouldn't be a problem, that anything learned while doing "other stuff" could only help. Besides, if you carried this to its logical conclusion, then constantly putting in overtime would lead to increased productivity. It's pretty widely accepted that's not the case. Sometimes you just need to think about something else for a while.

One of my points in the article was that developers should be responsible for the quality of their code. "How can you assure quality like that?" he wanted to know. "Surely they have some process in place for verifying fixes before they get committed." By that he meant code reviews, mandatory regression tests, talking it over with the testing group, getting approval from the test lead, etc..

I countered that many successful open source projects use a process of meritocracy. Developers earn the trust of their peers over time, and (except perhaps in a cycle's endgame) should be able to push whatever code they feel is needed. If you don't trust these committers, then they shouldn't be working on the project. If they screw up, then it's their responsibility and they've got to fix it pronto. See also Ryan Lowe's comments on this.

You can always vote people off, at least on reality shows and open source projects. Unfortunately it's not that easy in your typical workplace. If only our dream jobs came with someone like Lilo, who could find the one perfect place for everyone...