3 ms·

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 onl

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

by q2 12y ago

sytelus 12y ago

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.