5 ms·

The Google Way of Attacking Problems

97 points by frostmatthew 12y ago

dkokelley 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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-generator/ http://thefw.com/take-a-peek-inside-googles-internal-meme-ge...
      - OneMoreGoogler 12y ago
        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 12y ago
        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.
  - eitally 12y ago
    I wonder if you'd be more or less impressed by the back of bathroom stall door postings by the QA team, "Testing on the Toilet." http://googletesting.blogspot.com/2007/01/introducing-testing-on-toilet.html http://googletesting.blogspot.com/2007/01/introducing-testin...
  - fixermark 12y ago
    > 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 question is: Is it more or less efficient than alternatives, such as the fairly common practice of picking a software engineer out of a creatively-named-or-architected-hat and saying "You, you do it"? If your selection process doesn't account for interest, you're losing significant efficiency on interest mis-fit. Nobody procrastinates harder than a software engineer with an ill-fitting problem.
  - rifung 12y ago
    Considering the problem was solved over the weekend, it seems like this problem was solved in engineers' spare time. Since only the people who were interested would solve the problem, I imagine it wouldn't be too far fetched to think they could do this in addition to whatever else they were supposed to do as it would be fun for them. I imagine an ideal scenario would be something between just letting everyone do whatever they want and having some tasks assigned, as there might be things that nobody wants to do but obviously still need to be done. The right balance probably depends on the size of the company as well. For example I believe Valve is famous for not managing its employees and letting them work on whatever they want. I suppose they can only really do that because they are a private company though.
    - lrem 12y ago
      Weekend != spare time, once you are in an on-call rotation.
- deleted 12y ago
  [deleted]
deleted 12y ago
[deleted]
Animats 12y ago
Obviously, that doesn't scale. That's a weak article for HBR. The author should have described how Google does it now.
- mathattack 12y ago
  How does it work now?
  - msoad 12y ago
    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 12y ago
      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"
    - oaktowner 12y ago
      I joined Google after being at a big, soulless enterprise software company. Google is not the same. However, it is undeniably a big company. If you want to be at a startup, it's not the place for you. But it does "big company" better than most. We are treated amazingly well, we are well compensated, and we are surrounded by smart developers (all pretty unusual for bug companies). And, in general, people have a pretty wide latitude in heat they do -- especially engineers. And if you get tired of a particular project, movement between teams is encouraged.
seccess 12y ago
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.
dkarapetyan 12y ago
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 12y ago
  "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.
  - deleted 12y ago
    [deleted]
  - deleted 12y ago
    [deleted]
  - dkarapetyan 12y ago
    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.
- Bahamut 12y ago
  You can hire the people who think in this way though - they tend to populate graduate school (math, physics, etc.). That is one of the places Google hit hard when it came to hiring, which is partly what generated blockbuster success after cementing search - Google got to cherry pick some of the best of the best from graduate programs, and Google benefitted immensely from their minds.
- Retra 12y ago
  You're being overly pessimistic. Feynman's 'algorithm' isn't nothing, it's actually very rudimentary and important. The act of writing the problem down requires you to have a language for discussing it. You also have to be able to specify what you are looking for in a solution. (That is, how do you know if you've solved the problem?) Then you work to produce a set of transformations from one to the other. That is the best way to purposefully solve any problem. Just read between the lines a bit...
Donzo 12y ago
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.
DigitalSea 12y ago
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.
- lttlrck 12y ago
  Is this really Kanban? How is it different to a team working through issues in Jira?
- alasdair_ 12y ago
  Out of interest, what does a developer do if they are hard blocked on an item? Can they work on a second task?
- NeutronBoy 12y ago
  How do you ensure that the cards marked Priority are actually worked on as a priority?
crazychrome 12y ago
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 12y ago
  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.
q2 12y ago
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 12y ago
cromwellian 12y ago
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 12y ago
  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 12y ago
    You can PM me on G+ https://plus.google.com/+RayCromwell/posts https://plus.google.com/+RayCromwell/posts

97 points by frostmatthew 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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-generator/ http://thefw.com/take-a-peek-inside-googles-internal-meme-ge...
    - OneMoreGoogler 12y ago
      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 12y ago
        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.
- eitally 12y ago
  I wonder if you'd be more or less impressed by the back of bathroom stall door postings by the QA team, "Testing on the Toilet." http://googletesting.blogspot.com/2007/01/introducing-testing-on-toilet.html http://googletesting.blogspot.com/2007/01/introducing-testin...
- fixermark 12y ago
  > 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 question is: Is it more or less efficient than alternatives, such as the fairly common practice of picking a software engineer out of a creatively-named-or-architected-hat and saying "You, you do it"? If your selection process doesn't account for interest, you're losing significant efficiency on interest mis-fit. Nobody procrastinates harder than a software engineer with an ill-fitting problem.
- rifung 12y ago
  Considering the problem was solved over the weekend, it seems like this problem was solved in engineers' spare time. Since only the people who were interested would solve the problem, I imagine it wouldn't be too far fetched to think they could do this in addition to whatever else they were supposed to do as it would be fun for them. I imagine an ideal scenario would be something between just letting everyone do whatever they want and having some tasks assigned, as there might be things that nobody wants to do but obviously still need to be done. The right balance probably depends on the size of the company as well. For example I believe Valve is famous for not managing its employees and letting them work on whatever they want. I suppose they can only really do that because they are a private company though.
  - lrem 12y ago
    Weekend != spare time, once you are in an on-call rotation.
deleted 12y ago
[deleted]

deleted 12y ago

[deleted]

Animats 12y ago

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

mathattack 12y ago
How does it work now?
- msoad 12y ago
  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 12y ago
    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"
  - oaktowner 12y ago
    I joined Google after being at a big, soulless enterprise software company. Google is not the same. However, it is undeniably a big company. If you want to be at a startup, it's not the place for you. But it does "big company" better than most. We are treated amazingly well, we are well compensated, and we are surrounded by smart developers (all pretty unusual for bug companies). And, in general, people have a pretty wide latitude in heat they do -- especially engineers. And if you get tired of a particular project, movement between teams is encouraged.

seccess 12y ago

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.

dkarapetyan 12y ago

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 12y ago
"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.
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
- dkarapetyan 12y ago
  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.
Bahamut 12y ago
You can hire the people who think in this way though - they tend to populate graduate school (math, physics, etc.). That is one of the places Google hit hard when it came to hiring, which is partly what generated blockbuster success after cementing search - Google got to cherry pick some of the best of the best from graduate programs, and Google benefitted immensely from their minds.
Retra 12y ago
You're being overly pessimistic. Feynman's 'algorithm' isn't nothing, it's actually very rudimentary and important. The act of writing the problem down requires you to have a language for discussing it. You also have to be able to specify what you are looking for in a solution. (That is, how do you know if you've solved the problem?) Then you work to produce a set of transformations from one to the other. That is the best way to purposefully solve any problem. Just read between the lines a bit...

Donzo 12y ago

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.

DigitalSea 12y ago

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.

lttlrck 12y ago
Is this really Kanban? How is it different to a team working through issues in Jira?
alasdair_ 12y ago
Out of interest, what does a developer do if they are hard blocked on an item? Can they work on a second task?
NeutronBoy 12y ago
How do you ensure that the cards marked Priority are actually worked on as a priority?

crazychrome 12y ago

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 12y ago
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.

q2 12y ago

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 12y ago

cromwellian 12y ago

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 12y ago
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 12y ago
  You can PM me on G+ https://plus.google.com/+RayCromwell/posts https://plus.google.com/+RayCromwell/posts