peerreviewI was hanging the other day with some ex-Google folks.  There are more and more of these as the search company matures and the fact that I’m running across a few is, in itself, meaningless.  But without giving away any trade secrets (which the ex-Googlers absolutely refused to do) these chance encounters have opened my eyes a bit to how things actually function inside the Googleplex.  It’s different, really different.

Google isn’t organized like any tech company I’ve ever worked in, that’s for sure.  Peer review seems to be at the heart of nearly everything.  Yes, there are executives doing whatever it is that executives do up in the Eric/Larry/Sergeysphere, but down where the bits meet the bus most decisions seem to be reached through a combination of peer review-driven concensus and literal popularity polls.

The heart of Google is code and all code there is peer reviewed TO DEATH.  The result is absolutely the cleanest code in the digital world, forced into that condition by what can be a torturous process of line-by-comment-by punctuation mark analysis sometimes over-driven by people who take their work WAY too seriously.  You know the type. Peer review wars have apparently been known to break out at Google, though rarely. Usually the pedants are accommodated and, in fact, they for the most part win.  The code is clean as a result, but the process is s-l-o-w, or so I’ve been told.

And the code had better be clean, because at Google developers outnumber testers by 50-to-1.

But peer review at Google goes way beyond looking at the code.  Hiring requires peer review.  Promotion requires peer review.  Presumably even firing requires peer review, though I didn’t have anyone actually tell me that.  All the technical workers at Google are involved in peer review activities a LOT of the time — up to 20 percent, in fact.

Which brings us to the vaunted 20 percent time Google engineers are supposed to get to work on anything they like.  Most of them apparently use that time for corporate housekeeping — for doing all that peer reviewing.  It makes sense: if you want to appear productive in your main job yet are still required to do all this work that would normally be handled by managers, when else can you do it but during time you don’t have to account for?

This may be part of the reason that the Google 20 percent time hasn’t spawned as many new products as I expected it would.

But wait, if all the developers are effectively making management decisions through a peer review process, what are the managers doing? They are going to meetings, I’m told.  The typical Google manager has 50-60 direct reports and has time for nothing but meeting after meeting.  In a typical nerds-versus-suits scenario, the ex-Google developers I spoke with had no idea exactly WHAT their managers actually did.

Someone at Google is buying companies, I’m sure, and those decisions have to take place at an upper management level where checks are written, even at Google. What I find really interesting is what happens after the products are acquired.  Who works on them and what features get changed or modified? That, too, is apparently up to the engineers.

At Google I am told developers bid for what they want to do with their time.  If there’s a big job to be done people commit to parts of it.  And the parts nobody commits to do?  They don’t get done.  Really.  So when we wonder exactly how a JotSpot, which I really liked, turns into a Google Sites, which I really don’t like, that morphology apparently comes from people changing what they want to change.

There is no marketing input.

Effectively, there is no marketing.

I am not making this up.

This approach isn’t without precedent.  I saw much the same thing during the early days at Apple where new products were entirely driven by engineering.  Engineers built whatever they wanted to build and it was up to the company then to sell it.  Google apparently operates in much the same fashion.

All of this helps explain the Google tendency to have almost eternal betas, because there are no marketing-driven deadlines… ever.  And why should there be? Given that most Google products aren’t intended to directly produce revenue, it may not matter.

This explains, too, how Google products — even those popular with their users — sometimes just fade away.  Nobody wants to continue to support it, so the product dies.

Google is not your father’s software company, that’s for sure.  The fact that it works so well (makes so much money) comes down to the realization I had that Google isn’t a software company at all.  It’s an advertising company.

Ah, now THAT makes sense.

I, Cringely readers from the Boston area who want to see if I reflect light in person can run that controlled experiment next Thursday, September 17th, when I speak to the Society for Information Management’s Boston Chapter.  Here’s the link. My topic is Consumerization of IT: Is Corporate IT about to Lose Control Again? The answer of course is “yes,” but the devil is in the details. Please attend if you can.

Consumerization of IT: Is Corporate IT about to Lose Control
Again?