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.
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.
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.
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.
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?
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.
(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.
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!
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.
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.
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"
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.
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.
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!
> 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.
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).
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.
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.
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.
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.
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.
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.
