The Google Way of Attacking Problems

Articles like these remind me of the Feynman algorithm: write down the problem, think really hard, write down the solution. There is nothing to see here. There will never be another google. It will be another company and it will succeed for a different set of random reasons than google did. You can't recreate the process just like you can't recreate Feynman and his algorithm for solving problems.

There's no way to remove survivor bias from these kinds of business advice articles and books.

For me personally, its not that Google's success is the marketplace can be causually linked to this culture. It's more that I like working at a company where the majority of managers aren't douchebags, that people don't fly into nerd-rages over simple disagreements, and that in general, people are pleasant to work with here, usually wanting to help, and frequently focused on problems, nor interpersonal issues.

There's still egos for sure, but I've worked at many companies before Google, and Google culture has the least amount of these kinds of negatives. Perhaps Facebook is the same way. The stories I hear about Apple and Microsoft however (if true) don't make me want to work there. I'm not interested in management-by-verbal-harassment and North Korean levels of inter-departmental secrecy, not compartmentalized turf wars that exist in other companies.

I'd say the goal should be to make a company where people feel comfortable to apply their passions without too much "drama" from management and co-workers. Maybe that's not the best way to run a company that maximizes shareholder value, but it is a good way to keep people's blood pressure level.

Kanban.

The team I work on with exception of priority tasks that need to be handled by particular developers through manual assignment (which is often rare), we use Jira and Kanban methodology.

Developers get to pick their own cards to work on. A developer is only allowed to work on one card at a time. This allows a problem to have 100% focus by a developer. We follow the strict rule: nobody is allowed to assign a card directly to a developer. Nobody is allowed to side-step work in and go and ask a developer to do something (especially if they are working on something else). All work goes through a process.

We have a priority column. The product team is only allowed to add a maximum of 3 priority cards to be picked by developers. We stick to this pretty strictly. The key to something like this is implementing rules and abiding by them.

The biggest issue for me back in my agency days was the fact you would be expected to do many things at once and given such little time. Multitasking in a high pressure environment with a deadline looming and all of this work piled onto you means you make tonnes of mistakes. Not to mention people walking up to you and asking you to do things (mostly designers). Picking your own task is beautiful in that you know what needs to be done, you don't have to worry about anything else except that one task.

Having strict channels and a loose process for developers to self-select their own work actually works really well. And in my experience with my current team, it works incredibly well even within a somewhat large organisation spread out over various time zones from Australia, to India, the UK and the US (both coasts). The less hands on you are with an experienced development team in most cases, the better it will thrive.

I have a more recent example of this: I knew a Google software engineering team which writes all open bugs for their product on a whiteboard. If you want to tackle a bug, you put a post-it note with your name next to it and then go fix it. Nobody is every forcibly assigned to fix a bug (with the exception of security bugs). I think they had it where you could only have one post-it on the board at a time.

The book, "How Google works", is an arguably self-glorified interpretation of a rare success story. This article, is a re-interpretation of the interpretation. I seriously doubt if there is any value at all.

I think HBR is a major source of management BS. I haven't done the research yet but I bet it has published tons of articles in late 90s about how Apple's culture sucked, and then after its resurrection, how it worked so wonderfully well.

My point is, go create your own billion dollar business, and let HBR package your culture later!

When you worry about scaling the anecdotal example, you miss the message. The main idea here is that delegation and management can get in the way. Sometimes it is better to throw a problem up in the air and see who takes a swing at it. The "air" could be the kitchen or any other common space, digital or physical.

Obviously, that doesn't scale. That's a weak article for HBR. The author should have described how Google does it now.

I think the key takeaway from this is that culture is self-selecting. If you are responsible for a growing company, culture will dictate whether you are able to attract and retain the best people for the job.

Can any one confirm, this incident is the only time, Mr. Page wrote something on the kitchen walls? or he may have written several times, several things but only this got noticed and worked upon? In any case, this example as some "indicator" of Google's way is exaggeration with the level of available details.

There are lot of details we do not know and we may never know about what/whom led to what/whom precisely. Hindsight always appears precise. So please do not get fooled by hype/halo effect/propaganda/marketing...etc.

Conclusions may give wrong sense of comfort that inputs and the reasons provided are complete,sufficient. But it is doubtful and to write such a article, you can go backwards i.e. you may pick some evergreen conclusions/facts, take a popular success related to Apple's iphone or Google's search engine ...etc, pick a obscure/bizarre incident related to that, add relevant story lines/hypothesis in support of those conclusions and you may have a valid article.

Please note that, I am NOT saying this article is written in that way but getting those conclusions from a minor incident like writing on walls, attributing the solution -entirely- -only- to that incident appears like a stretch of imagination. Several past articles in the main stream media can be seen, where both successes and failures in the life attributed to strange/bizarre incidents rather than real hard work, sweat,planning ...etc.They appear like a part of Hollywood movie rather than reality.

APPEND 1:

What message should we draw?

If you are CEO of small startup, rather than talking to your team directly about real issues, write on kitchen walls or do some unconnected/unexpected thing where employees may not notice or understand the gravity/criticality of situation? If you do that and fail, some other management expert may write an article, criticizing your way of doings, which explains only success counts/matter but not methods for some people.

If you are an employee, then should we start looking at walls of the facilities for communication on important stuff rather than usual emails...etc and if by chance, some thing is noted, how do we know what level of importance should be attached to it or focus on it while ignoring the committed items in the pipeline?

Since Google became successful, that incident is lauded but if it failed, CEO and culture of the company will be criticized for insufficient communication. i.e. please avoid such communication to increase probability of success.

APPEND 2:

Downvoters: Please provide reasons so that if my reasoning is wrong, I am ready to be corrected. Downvoting without reasons won't help since I do not know what caused disagreement. Thanks.