
The Google Way of Attacking Problems - frostmatthew
https://hbr.org/2014/12/the-google-way-of-attacking-problems
======
dkarapetyan
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.

~~~
melling
"There will never be another google."

Perhaps not, but there must be another group of start-ups with really smart
people who value this type of culture.

~~~
dkarapetyan
Let me know if you find it. It sounds good in theory to say you value the ego-
less problem solver but in practice it works out a little differently.

------
cromwellian
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.

~~~
mitochondrion
For some time now, I've been deeply interested in what Google is like "inside
the veil". Would you mind if I privately asked you a few questions? HN doesn't
seem to have a PM system, though, perhaps a reddit or other forum PM?

~~~
cromwellian
You can PM me on G+
[https://plus.google.com/+RayCromwell/posts](https://plus.google.com/+RayCromwell/posts)

------
DigitalSea
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.

~~~
NeutronBoy
How do you ensure that the cards marked Priority are actually worked on as a
priority?

~~~
nostrademons
(Never worked on a Kanban team per se, but I worked on several teams at Google
that used this system under different names.)

You don't. However, you incentivize people who work on the gritty, hard-to-do,
high-priority problems. Come promotion time these are usually the people that
get promoted, and get their pick of further projects.

The reason this system works is that it implicitly trusts your developers.
Most developers don't deliberately _want_ to work on stuff that is useless and
nobody cares about. However, they often _don 't know_ what the priority tasks
are, or management's judgment of a high-priority task is actually blocked by
some other seemingly low-priority task, or they're afraid of spending lots of
time on something that other people won't recognize as important. By getting a
written record of which tasks were judged to be important by the team and who
did them, many of these fears are alleviated.

------
seccess
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.

------
crazychrome
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!

~~~
remarkEon
I had the same reaction.

One part of the book that I found really odd was when they seemed to glorify
the fact that resumes and hiring decisions went literally all the way to the
top. It seemed like a weird instance of intense micromanagement. I'm on the
way out of the Army, and believe me when I say I've encountered awful
micromanagement.

------
Donzo
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.

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

~~~
mathattack
How does it work now?

~~~
msoad
From what I hear from Googlers, just like any other big soulless enterprise
software company like Cisco or IBM.

Maybe I don't meet super passionate Googlers. Most of people who work for
Google are bored with their job and it's "just a job".

~~~
zem
i joined google three years ago, arguably after it had already morphed into a
"big company", and it's still a wonderful place to work. the main point about
that article that resonated with me is that when things break, the company
culture is still "we have smart, motivated people - we'll fix this" rather
than "who can we hold accountable"

------
dkokelley
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.

~~~
hnriot
my takeaway was amazed that something posted in "the kitchen" is even read by
anybody. For a technology company that's a pretty low tech multicast.

as for the actual point of the article, it seems highly inefficient to post
problems and assume the right (interested) people will take them on. The
obvious problems with this is scaling, and how do you account for people not
working on the things that they were supposed to be doing. Basically, it's
only something tenable in very few situations and only when a company is at a
certain size. It wouldn't work today, for the most obvious reason that Google
has a lot of kitchens!

~~~
dkokelley
Perhaps the point was that company culture let this work despite the obvious
issues with efficiency and priority conflicts. You're absolutely correct that
this tactic wouldn't work in today's Google, but if company culture has
persisted, it might still work within internal teams (albeit in a much less
visible fashion).

~~~
zaphar
The kitchen was replaced with memegen[0]. The same principle still applies
though. Someone complains about a problem. Engineers all around the company
brainstorm and implement a solution to said problem. It's a unique and
difficult atmosphere to grow in a company.

[0] [http://thefw.com/take-a-peek-inside-googles-internal-meme-
ge...](http://thefw.com/take-a-peek-inside-googles-internal-meme-generator/)

~~~
OneMoreGoogler
During my one year at Google, the problem with the most complaints by far on
memegen is Android L's "safety lock," requiring an extra swipe up before
entering the unlock code.

This is an edict from the design team, which engineering brainstorming cannot
overcome. Furthermore, the majority of engineers cannot implement a solution
even if they cared to try: they lack permission to access the development
Android source repository.

Maybe it's different in other product areas, but from where I sit, the
atmosphere you describe feels like a myth that Googlers tell each other, and
not part of its culture today.

~~~
zaphar
I can't speak to your particular experience but it's a single datapoint from
one year for one person.

I no longer work at Google but for the nearly 7 years I was there while not
every complaint got handled by a group of engineers like described in the
article, a startling number of them were. It was still very much a part of the
culture when I left and I would not be surprised to discover that it still
was.

------
q2
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.

~~~
sytelus
You are missing the point that Eric Schmidt's book is making.

I think successful software developers can generally be put in these
categories:

1\. People who gets assigned work done.

2\. People who figures out what their assigned work should be and gets it
done.

3\. People who absorbs everything that is going around in team, figures out
the biggest problem they are facing and gets it done.

4\. People who absorbs everything within their teams + outside and
_anticipates_ the biggest problem future holds and gets it done today.

In short, being great coder just puts you at Category 1. For higher ups you
need lots of ambition, vision, sense of mission, independence, intrinsic
motivation and persistence. Most companies just want their employees to be
able to "get work done" and they usually believe that management chain aka
"leadership" would bring other qualities to the table. It's considered as
management's job to figure out what the big problems are, break it down to
tasks, make schedules, monitor progress and so on. if ads had a problem at
Yahoo, for example, CEO might go to VP and ask him to fix it and then VP rolls
this down the chain. The book says that Google breaks the mold here. Instead
of CEO going to VP and management eventually assigning tasks to someone, he
expected employees to just get up and take an action out of disgust and
violation of sense of their mission.

One "issue" is that these kind of people don't like to be "managed". They
generally don't want someone telling what they should be doing, track their
status and so on. This was the reason Google used to had managers with 30-100
reports. One intended effect was that managers would be forced to interfere
less with their reports and not be able to look over engineers shoulders or
decide for them what exactly they should be doing. At most other companies it
is unimaginable to have that many reports because the very first question
people would ask is how would one manager can keep track of what everyone is
doing? These companies inherently are designed to attract category 1. There is
exponential difference in outcomes between each of above listed categories.

