I question the title. It doesn't sound like engineers are in charge, instead, it sounds like smaller operating units will be in charge. That is a very different thing from having the inmates running the asylum.
I have yet to see a large company that successfully treats software as a creative endeavor instead of a production line that still manages to be able to focus on solving customer problems. I really hope that Larry figures this out because, if he does, that will (IMO) be his greatest legacy.
What I think will happen, though, is Google will focus even more on technology and care even less about actual users.
Not even smaller operating units, it just sounds like things will be organized according to product rather than function. Other HN articles recently have mentioned how Google has a bunch of centralized organizations that report all the way to the top and are not responsible to any product group (Launch, Site Reliability, UX, Product Management, etc).
What's different about Android is not that Andy Rubin has an engineering background; many of Google's senior managers do, even in the big functional orgs. What's different is that Android is a product unit which largely does not depend on these external functional teams and has all its resources built in.
the moment Google has several product teams each having all their own resources built in - like Launch, Site Reliability, UX, Product Management, etc - there would start to appear smart people with great ideas of combining similar functions from different products group into separate function groups to increase synergy and efficiency.
This sounds to me like a Home Depot -> Lowe's relationship.
I guess you'd have to master "being Google" first, so since G's business model is much much less settled than Home Depot's it will probably be a while. After all, there's still no "Fry's with good service," so maybe it's the B2C tech industry itself that precludes (good) customer service in general.
This is complicated by the existence of customer-focussed companies/sites like 37Signals and Craigslist, so maybe the difference is that customer service has to be a charter goal of the company in order for them to be any good at it. Just spitballin'.
The central problem of B2C tech companies is that their value proposition is to make complex things simple enough that the everyman can have them. When things go wrong, they can go wrong in literally millions of ways, because there are literally millions of everymen. Fixing those one-off problems is not a scalable business proposition.
Companies like 37signals and Craigslist manage to keep a good rep for customer service by ruthlessly pruning what's expected of them. 37signals wants only a certain type of customer, usually a fairly technically savvy small business. If your needs differ from that, 37signals' customer service sucks as well, but they just say "We don't want you as a customer" and that's that.
Craiglist works by managing expectations - they're a classified ad service, no more, and no less. If the hooker you paid for turns out to be an FBI agent, that's your problem. If the contractor you found turns out to suck, that's your problem. There's no expectation that Craigslist will fix it, while there is a widespread expectation throughout the general population that Google is the Internet, and if the Internet sucks, it's Google's problem.
>widespread expectation throughout the general population that Google is the Internet, and if the Internet sucks, it's Google's problem.
I was in agreement until this. I think this is an unfair characterization. The huge problem with Google's (lack of) customer service isn't because they wont fix bad sites on the Internet. It's that they provide incredibly bad service for their own stuff.
Suppose that Google picked 4-10 different startup-sized groups and anointed them as "customer support organizations". The companies could provide customer support for Google applications to the public (and could charge the public as much or as little as they wished for the service).
For it to work, Google would have to be willing to be more open with these support companies (hence the anointing of a few). The companies could provide care and hand-holding for customers, but eventually some percentage would need to result in actual bug reports and actual technical troubleshooting that could only be done by Google. Today, no one can offer this service because there's no way to open a support ticket with Google -- they're too closed. If they would open up slightly, even for just a hand-picked few, then this might be a way for Google to offer excellent customer service without doing it themselves. The customer support organizations would compete with each other on customer service and would also compete with each other on how easy-to-work-with they are for Google engineers: perhaps Google should even charge them varying amounts depending on how well they do this ($10 for a well-researched bug report; $150 for a poorly researched one).
Didn't mean it couldn't be Google. Just that its something they need to work on and whoever figures it out will get a pretty big spot in the history books
I agree that the article does seem a little tabloid, but I think speculating on what will happen to G as a complete outsider is to a very high degree a gamble..
There would be so many issues at play here.. How well can Larry get buy-in from various levels of the organisation? How well will the Google culture evolve around his proposed changes? What will they do to ensure Quality of service goes up?
At the end of the day, Google right now is a one trick pony. General consensus in this thread is that Android is successful within Google right now. I don't buy into that though primarily because it's a business unit that does not make any money...
I think there's a long way to go and a lot of forces at play
This is a big story. I'm both an engineer and a manager (to which engineers will say "management!" and managers will say "developer!"), and I haven't seen this pendulum swing back and forth so much as be ripped in half and pulled in opposite directions. Google's obviously got very smart folks in both engineering and management, so it's going to be very interesting to see how this is handled.
I can't imagine a Microsoft, Sun, Oracle, etc going through this exercise, so I'm seriously rooting for Google. It'd be lovely for this change to produce some real knowledge on how to run a modern, big, high-speed tech company without getting trapped in the argument over engineering-vs-management.
Right, but even the Windows unit itself is probably at least 7 or 8 layers deep, due to the sheer number of people working on it. With such a massive product, I'm amazed they release it as often as they do, let alone at all.
I think both have their merits, but I think engineers should be the ones building projects/companies, and management should be the ones who run it. I don't think non-technical management should fundamentally be involved in development unless it's a manager who is also an engineer. In a sense, a traditional non-technical manager should be in charge of the monotonous, boring stuff and that only... stuff like QA, ops, marketing, etc... Basically maintenance-mode autopilots.
I'm a big fan of engineers turned manager though, after working with several different projects at my last company. The only problem with that is when their manager isn't an engineer and you end up with the same disconnect that you would normally get at the dev/manager level. It sounds like Google is, in reality, trying to eliminate that disconnect entirely, with managerial engineers the entire way up to CEO.
The problem with this approach is that engineers are going to build things that other engineers like. Add up all the engineers in the world and it's not that much compared with the rest of the global population. A good comment on the original post stated that what Google really needs is to diversify it's workforce. This is the reason Google fails at social.
I could see something happening like at Yahoo where different groups of people end up developing the same thing, both with different benefits, and have to kill one off.
It's awesome to see a fundamentally engineer-driven company like Google and a fundamentally designer-driven company like Apple become so successful. It has always seemed to me that management is an important but overemphasized skill (as a fundamental trait of the way large organizations work) and it's really refreshing to see this happening.
[Edit: I worked at Amazon Web Services until recently. Now work at Google. Concern for customers drives everything that happens at Amazon, sometimes to a ridiculous degree.]
This was addressed well by someone from Netflix but I can't find the link. Basically he said that Reddit weren't so much the victim of AWS rather than the victim of not understanding the product enough and not spending enough to buy the right instances and thus ensure their constant performance. The guy from Netflix justified this by the way that the different sized instances are split across their respective hosts and, surprise surprise, if you buy the bigger instances you get more of each machine host and less threat of someone taking you out.
If that were true, you'd think that would be the first thing they were told when they started complaining about crashes a year ago. Certainly, you'd think by the time they had talked to the CIO, somebody would have said, "you guys need to buy bigger instances". We know money isn't a problem for reddit anymore, and all current and former employees have said the problems with EBS just aren't something they can fix by throwing money at.
I would suggest the guy from netflix simply doesn't know enough about reddit's particulars to offer an informed opinion. Either that, or he knows better than everyone at reddit, every support person at amazon, and even the CIO of amazzon how best to solve reddit's problems.
> I'd put them right up there with Apple on the product innovation front.
Could you elaborate on that? I can think about only two potentially innovative products coming from Amazon.
1. Kindle. The business model is definitely innovative, but the device itself had a cold reception. The modern versions are much better, but still don't reach the Apple level of polish.
2. AWS. Extremely innovative, but targeted to a relatively small population. This is definitely not a mainstream product.
I intentionally skip the innovations in streamlining the shopping experience, because I don't feel it's relevant to the comparison to Apple.
Amazon's main strength is building platforms for other businesses , and innovating business models. their product innovations are just tools to build platforms.
You can see this from a list of their innovations:
1. amazon fulfillment services.
2. the affiliate marketing method.
3. 3rd party sellers arena, used book selling arena inside their own store.
4. the kindle - a digital platform for many authors and publishers. the physical kindle is not that hard, just look on how many e-readers are there.
5. aws - a good product, but also an innovative business model.
In the tech industry this isn't really an issue (management being overemphasized). Even at places like IBM and Intel you generally have engineers running the show at every level of the engineering org.
I think what Google will see is that the real problem is the board and shareholder accountability. This creates a special type of short-term malfunction in organizations which often looks like a management problem, but really isn't.
> In the tech industry this isn't really an issue (management being overemphasized).
The thing is, in a lot of larger tech companies, I suspect it's the other way around: management is under-rated because the engineers have taken over the asylum.
It's easy to point to huge, successful companies with a very pro-engineering culture like Facebook and connect the culture with the success, but how do we know they succeeded because of the culture and not in spite of it? Certainly Google has produced a string of flops in recent years that would have killed most companies without the core search engine and arguably now mail and Android groups to prop them up. Facebook succeeds because they got a couple of basic things right in the early days and the networking effect is a massive barrier to entry for any potential competitor, not because all their engineers keep coming up with great ideas that lure people away from the competition.
I wonder how robust these companies really are, and how much their management structure (or relative lack thereof) will influence that robustness if in future they meet heavyweight competition or, more likely, disruptive competition that moves the market.
You point to recent Google failures, but isn't their culture of allowing (even high profile) failures not only to get implemented, but then to get shut down part of why Google's successful? Which (the culture of allowing failure) seems like an engineering approach, and not a managerial (which to me has always struck me as fear-of-failure/CYA) one.
That's exactly his point. Both Facebook and Google have secured market domination to a level where their culture, be it engineering or managerial, doesn't really matter.
The question is whether those flops should have ever happened. I admire Google that they will kill unsuccessful products, but I question how well they understand the market when they have so many products to kill.
Lots of failures is "working as intended". The only way to understand the market is to try out lots of things and see how the market reacts. Remember, the point of innovation is to solve unmet consumer needs - if people understood them, they wouldn't be unmet.
I still think it's worthwhile to distinguish between failure of execution and failure due to factors beyond your control. Buzz and Wave certainly had market challenges but they were seriously hampered by some poor decisions.
I think that is one way, but not the only way. Apple is able to release products that are generally well received by the market. In fact Apple understands the market for their individual products extremely well, even if the product isn't released yet. Google's approach seems to be more of a shotgun/spaghetti see if something sticks, without actually stopping to think things through first.
The spaghetti cannon strategy. Microsoft do this too.
Apple does not follow the spaghetti cannon strategy. However the risks of manufacturing a device that doesn't sell is higher than launching a website that nobody uses. It makes sense for Apple to take their time. As a side-effect they've accumulated a huge stockpile of cash.
Isn't Apple targeting more of a niche than the general market, though? They service that niche very well, but it's easier to understand a niche than it is to understand the entire body of consumers.
most companies fail, even the ones run by those who "understand the market" (if that phrase has any meaning outside of speaking completely in hindsight).
Management is great at extracting maximum value from a problem whose structure is known. For new problem spaces where the product is ill defined, management might just slow things down. It might be worth noting that as the world is moving into more uncharted territory (of shorter product cycles) industry is beginning to resemble academia to a greater extent.
It's easy to point out Google's mistakes and point to their engineering culture, but look at Microsoft as a counterexample. Microsoft has more or less the same story as Google; one or two wildly successful products supplementing the rest of the business. The other groups at Microsoft leap into new markets to try and expand the core business (Xbox 360 being a fine example). I doubt we would call Microsoft's culture an engineering culture in the same vein as Google.
> Microsoft has more or less the same story as Google; one or two wildly successful products supplementing the rest of the business.
Really? I think if you list Microsoft's product lines, only a relatively small proportion failed badly. Sure, Zune never took off and their various on-line efforts haven't exactly had stellar results. Still, it's not like MS only makes money on Windows and Office. They also have a very successful range of server products aimed at businesses. Their initially loss-leading efforts to penetrate the computer game market are now doing pretty well. They even make good keyboards and mice.
Now, here's the kicker. Microsoft do effectively give away a couple of things, notably software development tools and IE. They also run Microsoft Research, which is where a respectable amount of serious work on the future of both programming and HCI is going on today. However, these things are done in a way that supports their overall business interests, which is exactly the sort of strategic decision that good management needs to be getting right.
I'm hardly a Microsoft fanboy, as many of my previous posts will confirm, but I don't think they have been anything like Google or Facebook in terms of hit-to-flop ratio in recent years.
People on HN have this weird distinction where if your an engineer you stay an engineer. In the real world, most career structures involve coming in a engineer and then progressing into management. A lot the skills used for management such as negation skills just come with age anyway.
I respectfully disagree. I believe that knowing when and how to say "no" is one of the most important management skills, and I suspect that understanding the need to say "no" a lot more than "yes" in the early days of a project (or a whole business) is quite strongly correlated with success.
I think he meant to type "negotiation" rather than "negation", which makes little sense even if he was trying to convey the point you just made. So I was making a little fun of that. I agree with you.
Can someone who works at Google chime in with what the organizational temperature is like at Google? Does this whole 'party time's over for the managers' thing we're hearing about have any real weight to it?
I'd like to ditto this; the linked article is very speculative, and without a G-employee response, it seems rather foolhardy to extend said speculation.
agreed, especially in light of the stories we just heard about technical skills being valued less in managers there. I think this is someone just coming up with a nice narrative.
To add an unrelated reply to a crowded discussion: I think that what we've seen from Googler manager skillset article in the Times is that Google has had to learn basic managerial attributes organically since that's the Google way -- from this outsider's perspective, it almost sounded like if they didn't invent it, it's hard-to-impossible to adopt given the startup culture.
I think that this board in particular has given Facebook a lot of praise; by this, I mean that there's a fascination/silent cheering for their engineering-driven culture. But I think that we're seeing a transition by Google from a startup (Facebook) to a real company (Microsoft); as much as a "management" layer is derided, a lot of Google's projects seem to have little business value; while they may eventually become valuable, it seems like their strategy has been to shy away from placing limits and directing units towards hard business goals (profitability).
But I'd argue that the rise of "business" being more important than passion-projects (which is what we implicitly view Google as) has been very visible, just ignored. Android's device manufacturers producing under anti-fragmentation clauses comes to mind as a sterling example of a unit posing to follow Google's motto but in reality has them running in the opposite direction (e.g. away from openness).
So, to round back: sure, anything could happen in regard to managers; but Google's in the middle of growing pains, and those pains I believe will end in an increased managerial presence/layer rather than ignored outright.
It's also similar to how Berkshire Hathaway is run; and how Christensen advocates nurturing disruptive businesses - smaller units can get excited about smaller sales that are a rounding error to Big Google (new markets start small); independent units are free to customize their business model and how they do things to what fits the opportunity (instead of fitting in with the parent's model and processes - which has compelling economies, but only early).
e.g. it seems highly unlikely that advertising is the ideal revenue model for every business Google is in. The appropriate fit might be sales, renting, monthly charge, pay-per-use, royalty, per-developer, per-other-metric. It's not necessarily about extracting more money from customers, but revenue that makes sense for customers - that they prefer, that makes sense in the competitive set, that motivates the business to improve along the right dimensions.
Ever since "management" and the dedicated "manager" were invented, we have been told, increasingly in recent decades, that they, rather than talents in other roles, are the key to business success. With the increasing importance and accelerating pace of innovations in our time, it's time to test if to what degree such doctrine would still hold true. Good job Larry. That's some risk worth taking.
This got me thinking about role of managers in a modern org (to simplify things let's say it's a Tech company).
It certainly needs a CEO/Visionary, it most likely needs HR and front/back office folks, it certainly needs PR and marketing people. But in a world where people communicate rarely in person, have their own management and economics 101 abilities, are smart enough to not work against their own interests (and look after the org's interests) - what's the role of the future manager?
It sounds inevitable that senior Engineers will double up as managers for their group as and when required (working with marketing etc.) instead of it being a dedicated managerial position.
One of my ex managers said that his role was to attend the meetings,shield the developers from the politics of getting projects approved and other institutional overhead so that we could focus on delivering product.
There's a bit of irony in there that these are mostly people created distractions and the org throws more people at it in the hope of solving it!
I think there will still be need for excellent managers to get a diverse group of people to do stuff together, to keep the vision coherent and to motivate people to deliver their best. It's just that it's a lot to ask of one single person and the position is vulnerable to Engineers grasping those skills and having a huge advantage in actually understanding the low level stuff much better.
Sounds familiar. As a USMC fire team leader, my job was mostly to protect my Marines from all the shit that rolls downhill. It's generally a very difficult job to do well, because of the way the explicit incentives are set up, but somewhat easier for me as I was basically apolitical and had no career plans in the Corps.
I keep a blog about miscellaneous stuff at http://blog.byjoemoon.com (plug) but I don't think that's what you mean.
I got out in 2006, and I had already stopped writing by the time I made team leader, but I did keep a blog for some of the time I was in, and I collected it (the interesting stuff) at http://www.servicerecordbook.com.
This is a great role for a manager to play for as long they have the power to actually shield the developers from politics.
When things go bad politically for the manager and they lose that power, the politics have a way of suddenly rushing in and catching the developers off-guard.
So developers, inspect your manager for leaks regularly.
I ask because when I moved into management and worked with a stellar group of extremely experienced engineers, far better AND more experienced than I ever was, that's exactly how I explained my job to them.
Personally I've always seen the organizational structure of film and TV units as being a natural model for software development [1]. They've been doing the somewhat-controlled production of fundamentally creative product by small, focused and often-times transient teams for quite some time.
And in that model, the current manager type is less like the director [2] and more like a producer.
That is: a person who primarily manages logistics and external requirements.
e.g. arranging the times to get the necessary people together to review builds and such. keeping statuses up-to-date. keeping an eye on tasks and deadlines. keeping their finger on consultants. etc.
[1] Far more natural than the manufacturing model that corporate America is trying to fit things into.
[2] I'm sure managers would like to imagine themselves as directors. But they're typically ill-suited due their not understanding the creative nor technical sides.
This sounds like the studio model that the AAA video game publishers have been using for some years now. While they have in-house production and coding for many packages, more and more the big-name titles are implemented by small remote teams that focus on the meat-n-potatoes while marketing and distribution and project management is handled by the parent company.
But in a world where people ..., have their own management and economics 101 abilities, are smart enough to not work against their own interests (and look after the org's interests) - what's the role of the future manager?
I don't know if there's as many people who have these abilities as you think there are.
Likely not but it still makes sense to give a chance to all the few talented people however many there are to actually create something instead of manage other less talented souls. Better for productivity and happiness IMHO!
Large corps are hardly run for employee productivity or happiness. They are run to maximize short term personal wealth of managers, and (less importantly) shareholders.
Microsoft has done this all along. Managers are programmers, they divide their time between programming and managing. The feeling within Microsoft, was how can someone who is not a programmer, manage programmers?
I don't know of many engineers who would want to double up. I do agree that a well managed company could get by with far less management than most currently have, but don't think that just having really smart people in place will solve the problem magically. I've worked at a company full of incredibly smart people who couldn't get anything useful done because they were all so busy proving how smart they were, often at odds with others in the group.
What makes you think mangers don't suffer from the same thing. Managers are also highly educated often more so(MBAs etc) etc except they will be trying to employ fancy management rather than fancy algorithms.
I think many (middle) managers are afraid of Scrum and other agile development because their role is sidelined. As "individual contributors", engineers are generating actual business value. Engineers can self-organize in "quasi-communist" Scrum teams (as they own the means of production ;) and collaborate with product management who work with customers to derive and prioritize product requirements.
In this scenario, what is a "people manager" supposed to do?
The job of a people manager at Google is generally to keep the engineers happy and make them want to continue working for Google. Somebody has to be the point person for general career-development issues, so that if you get bored and frustrated with your current position, they can say "Here, check out this other group over in this other area of the company, you might enjoy working with them" instead of quitting abruptly. Somebody needs to make the high performers feel valued, and let the low performers know that they need to improve. Somebody needs to be the point person to handle things if a family emergency comes up and you need to take several weeks off, making sure that your responsibilities are covered by other people and all the administrative stuff is done.
The good managers are really good at this. The bad managers...well, I don't work in that part of the company.
People managers rarely do engineering work as well - it's very hard to both manage people well and contribute significantly to the code for a project. It also sets up a sort of perverse incentive where you want to look good as a coder by taking on the glamorous, high-profile programming tasks, but this can actually demotivate your teammates because they're left with the drudge work. You don't want to be in competition with your reportees.
They're often drawn from the pool of former high-ranking engineers, or at least the good ones are. It's a very different skillset though; part of being a good manager is knowing when to step back and let your reports handle things, and the worst managers are those that haven't managed to separate their engineering ego from their team building ego.
Very true. I worked for a startup some years back where the technical cofounder had a nasty habit of reserving all the interesting problems for himself and fobbing the scutwork off on employees. It was intensely frustrating. Yet somehow they never understood why they couldn't retain programmers...
I've helped organizations transition from waterfall to agile, and there was absolutely no decrease in the workload for management.
You still need some form of functional management to get the right staff, make sure they have what they need to be able to do their jobs, and deal with day to day issues. This might sound trivial, but it really isn't, and somebody who does this job well will enable a lot more success than somebody who treats it as a minor task.
And you also still need some form of product and project management to ensure that the work being done is aligned with strategy, marketing, sales, finance, etc, and to serve as an interface with those groups. Failure to do this effectively creates massive inefficiencies.
As such, I really don't think any moderately intelligent competent manager is at all concerned by Scrum, Kanban, XP, TDD, Lean, or any other Agile practice.
Smooth things out in the event of engineers being on the verge of shooting at each other. That is, manage human beings to let them work at their best, not timelines and general process flow to achieve a financial goal.
The scrum teams don't own the means of production. Individual contributors are human capital. The means of production are owned by the people in control of the finances and business model. If the company were to shift direction and your product discontinued, it's possible the scrum team would be disbanded and the resources that were being used to support them would be reallocated by the "owners" to a new team that aligned with their decision to shift strategy.
The team could also quit en masse and go found a startup to do what they'd been doing before, if they really believed in it. It's happened to more than a few big companies.
Ideally, but power still seems to be centralized to dealmakers (probably a function of human nature), whether they're specially skilled or not. Managers are essentially low-level dealmakers.
Ppl who can make win/win situations out of lose/lose situations are important. Isolated technical decisions are often the easy ones. The tough ones are getting two people or multiple groups to come to an agreement on technical decisions w/o any feeling like they were just burned or stabbed in the back.
This is basically Steve Jobs. Steve is the consumate manager. Not an extremely nice guy, not a designer, not all that technical. But people value and respect his opinion. And even more importantly people want to deliver what he wants.
You know a great manager/dealmaker because he's the person who when they change groups, you want to go with him because you feel like he'll take care of you and your projects.
From the "Dear John" letters of people departing Google (Dennis Crowley for example) it seems like in the absence of a large political institution, the major political currency at Google is your ability to attract developers.
Given that, it seems like what a manager can provide a group of developers and designers is "workforce maintenance". That is, they will attend to the needs of the team, make sure people don't leave, and make sure they attract more people when they need them.
In other words, HR. The central HR department at Google has no reason to really care about the success of your unit over another, so your manager becomes the person who takes responsibility for the human resources of the unit.
This frees the engineers/designers to be able to focus on creating a great product. And as a side benefit, they happier and their jobs are easier because the manager is doing what it takes to keep them in the unit.
The goal of management is essentially the same as the goal for any kind of political structure: remove issues which couldn't have been dealt with in a cheaper way.
Layoffs are routinely used as an opportunity to flatten organizations by removing layers of management.
I don't think I've ever seen a corporate reorg where middle management wasn't amongst the hardest hit groups. They're expensive, and you can usually fire a huge swath them without thinking, tell the remaining ones to start working late and limp along until times get better.
The reality of a large corporation like Google is nowhere near as simple an engineer-vs-manager dichotomy as many of the comments on this thread would make it. Products need to be developed, but they need to be supported and sold too. Which of these functions is most important depends on your world view and your tolerance for angels-on-a-pinhead debate, but it's undoubted that each of them are crucial.
An engineering mindset of automation and solution-by-algorithm gives us the miserable customer service that Google is famous for; a realisation that people are tricky and messy gives us something more like Zappos. The people who are good at support and managing support teams are not like engineers, and the people running sales are an entirely different breed. Rare is it to find someone who can successfully manage all three. Indeed, I would go out on a limb and say - as an engineer myself - that it's easier to find a non-technical person who can make a positive impact in product development than it is to find an engineering who can significantly improve sales or support.
Seems to work pretty well for Honda. They innovate and everyone still copies their designs and products, but they also have great financial results magically with innovative products. http://www.forbes.com/forbes/2006/0904/112.html [2006]
I hope this is a trend in America, Google can set a great example (as all companies early on do) on keeping innovators in charge with a startup culture/meritocracy.
Before the recent change in CEO, I felt Google was getting too suits focused and simply competing on a byline/reactionary technique. Bring it back Google.
BTW: I understand that Honda used to be very innovative in disruptive ways, creating entirely new categories of products (e.g. they invented the off-road recreational motorbike) but, like Sony, have instead only made sustaining innovations to existing product categories for the last two or three decades. Are my facts right? (I'm going by Christensen).
[I'm guessing merely sustaining innovations is the very thing Larry Page wants to avoid (and separate business units helps with that, because then they're free to fit themselves to the market need - like a startup).]
This may finally lead to outright combat between the ChromeOS and Android groups.
Chrome the browser itself is fairly successful, as are Android phones. But Chrome OS vs. Android...that is a huge showdown. ChromeOS is a minimalist OS, whereas Android is a fat client. Philosophies are totally different.
Attitude within Google right now is "let the market decide". Only a company with the free cash flow of Google could build two operating systems intended for mobile devices and take that kind of approach.
This doesn't seem all that different from the way car companies run multiple makes. Chevy vs Saturn. Philosophies are totally different (or at least they were) but the market is the same. This way the company does well whichever approach wins out.
This is such a good move! It gives Google the nimbleness, hunger, and guerilla mentality of a start-up in new areas it wants to explore through these small mostly-autonomous teams, while simultaneously allowing it to defend the already captured beachheads (search, gmail etc.) - all funded by the deep, deep, Google pockets.
In any innovation-oriented org, curious engineers and inventors need to be able to play and push the boundaries, but even large organizations with strong financial backs are so defensive when it comes to innovation, so afraid to fail, or waste resources on experimenting. Google has always been okay with this "waste". If you go back before year 2k and try pitching to a goliath sw company to let 20% of dev time be spent on employees’ projects of choice you'd get assaulted by the CFO. Google was okay with this "waste", because they knew if you let the right players roll the dice, every now and then you’d hit jackpot. And they did! Many of their most successful products came out of the 20% project.
Organizations today have split the vision and execution aspects of building something. The vision comes from management and the execution from engineers – this is straight from the defensive playbook - ‘engineers can execute with minimum risk, and managers are close to the customer therefore know what will sell for sure’. This kind of thinking will work when you want to improve marginally (like Henry Ford said something along the lines of 'If I asked my customers what they wanted they’d say a faster horse'), or if you are the market leader, but it will never cause disruption or let you make headway in uncharted territory. It is very important to know when to play offence and when to play defense.
The average investor went to the same school as the MBAs whose power may be diminished if this is true.
Management ideology includes the idea that a good manager can manage anything; that management is a context-free science that should be left to professionals. If you believe that then you believe that this article says Google will be turning over management to amateurs. Naturally you might be suspicious.
The problem with Google is that it is sized to deliver big brands, big scale and big projects.
First. Google today cannot deliver small brands because failure is very expensive. Every Wave, Buzz, Knol costs Google because future enterprises are less likely to want to try their products.
Startup culture could no longer exist in Google, because the salary means that the people will be taking risk with other people's money, and it doesn't work for early stage projects.
Secondly, Google cannot deliver small projects. I can relate this to my past history working at a large mining company, there are some mineral deposits that they may not develop but sell off because it is too small for a company their concern. The management overhead is simply too big.
Finally, to deliver large projects require specialist departments. The functional structure is there to deliver this. The alternative would be a matrix structure where there will be a lot of confusion as to who reports to whom, or serious duplication.
Good point ! Balance is key in everything. There is no one right way, and this is exactly why those in management should have a mature outlook in handling the allocated power.
A good example is how Kin was supposedly set back seriously due to infighting with Windows 7.
This brings to a head the interesting situation of the modern tech company. Unlike companies in almost all other industries, the average developer at Google (and a lot of other companies) needs to be much smarter to do the job than the manager.
So the skill pyramid is actually inverse compared the "military corporation" model. It's also true that many, perhaps even a majority, of the deveopers would be "even better" at management, marketing and strategy etc, than those normally filling these roles.
This situation really does beg for a solution beyond what the typical corporation/MBA paradigm has come up with so far. Kudos to Mr. Page for taking a shot at it.
In the case of Microsoft, no. The Office and Windows division are mutually-supporting rivers of gold. Everything else is the spaghetti cannon approach they've pursued since the 90s, with the possible exception of the Xbox.
Most of what Google does is not actually directly profitable and thus not ideal for spinoffs.
I'm not sure why people assume that Microsoft only makes money on Windows and Office. There were 11 separate businesses within Microsoft that brought in a billion dollars or more in revenue last year: http://techflash.com/seattle/2010/07/microsofts_11_billion-d...
Actually, I don't think you understand Microsoft's business model. "Server and Tools" may only generate a modest profit of only a billion dollars per quarter, but it is the foundation of all those Windows sales. The real core of the company is not the end-user stuff, it's .net, Visual Studio, IIS, and SQL Server.
If you're actually trying to arguing that MSN/Live/Bing has been an endless waste of money, then of course I'd agree.
I admit that S&T was an oversight on my part in my OP. But MSN/Bing/Live, various attempts at tablets, phones and all sorts of other doodads and geegaws have been money sinks.
I don't think they should be letting Managers or Engineers run things. I think they need to have... I'm not sure of the title... lets call them Vision Carriers. In the video game industry we call these people Creative Directors.
These vision carriers need to understand the product they are building and the people who will use it.
They don't need to be good a managing people or budgets, they don't need to write code. They need to understand what is good and what is bad and they need to be able to clearly communicate it to the team.
(Aside: I think the original article does not understand that product managers aren't "managers" in the traditional sense of the word. Much of this discussion should be predicated on this fact!)
I love when companies move back to their purer roots. I don't know where this puts Google's progress as a company over the next few years, but it definitely means we won't be seeing the innovation slowdown that Microsoft experienced after their years of explosion. As long as our tech superstars arn't just turning into company gobbling monsters, but rather are constantly iterating, innovating, and developing their product line like a company should.
There is a big difference between a manager and a leader. A manager takes the credit for things that go well and looks for people to blame when they don't. A leader understands that they are only successful if their team succeeds. A manager worries about how the team might screw things up. A leader thinks about how the team can exceed their goals. A manager tries to consolidate their power and protect their turf at all costs. A leader knows that the team follows them out of a sense of mutual respect and understands that if they can no longer effectively lead the team than it may be time to step aside. Leaders are not just found at the top of an organization.
Like I've stated before, this would be the perfect time for Microsoft to take Gundotra back and make him CEO.
They desperately need the same type of change at the executive level.
I mistakenly thought Larry Wall was the new Google CEO. It seemed a little odd at first, but then I thought it was very cool. Now it doesn't seem quite as interesting.
Certainly, Rosenberg has been crucial to Google’s success, so his exit has come as a shock to pretty much everyone to whom I’ve spoken.
That said, its timing seems quite convenient, particularly in relationship to what looks very much like a significant reorg that is currently underway at Google, said sources familiar with the situation.
Note first that Rosenberg’s replacement wasn’t immediately named and it’s not clear whether Page even feels one is needed.
Maybe Rosenburg helped Google do great things. Maybe I'm about to over-simplify. But weren't the things that made Google a true powerhouse created long before guys like this were hired -- back when the company was more engineer-driven?
It seems to me that Larry Page's frustration has been growing as he watched MBAs take credit for the success the engineers had created years before. If that's the case then I wish him success in changing the company's structure.
I think this is a great direction for Google, but it certainly is not a direction most other companies with equivalent growth can pursue. I think one of the unique aspects of Google, is the type of engineer they pursue.
I have yet to see a large company that successfully treats software as a creative endeavor instead of a production line that still manages to be able to focus on solving customer problems. I really hope that Larry figures this out because, if he does, that will (IMO) be his greatest legacy.
What I think will happen, though, is Google will focus even more on technology and care even less about actual users.