The Berkun Blog

Management, design, and the making of good things.

Archive for the 'Microsoft' Category

Speaking at Web 2.0 expo April 21-25th

April 8th, 2008

Later this month I’ll be down in SF talking at Web 2.0 Expo. I’m doing a half-day tutorial on How to Innovate on time, plus a keynote on the Myths of Innovation. The lineup includes Blaine Cook (Twitter), Matt Jones (Dopplr), Marc Andressen (Ning), Clay Shirky, Matt Cutts (Google) and more. Among other special events, there’s also an ignite talks event, one of my favorite things to watch, on Tuesday night.

If you use this magic code websf08sbg you get $100 off the registration price.


Web 2.0 Expo San Francisco 2008

Fresh thoughts on the Microsoft/Yahoo merger

April 8th, 2008

This is exactly the kind of topic I avoid here, but since the deal hasn’t been shot dead (at least not yet) as I’d expected, it’s time to throw an opinion on the pile.

The first thing that comes to mind is the 1995 attempt by Microsoft to buy Intuit. It doesn’t seem important now but at the time it was a huge deal: it would have been the largest software acquisition in history. Inside Microsoft, where I worked at the time, the move was a surprise, much like the Yahoo deal probably was (Hot/Big companies are news leaks, so execs rarely bother with early internal memos). The DOJ said no, but regardless it represented the same type of inspired, ballsy, ‘go all in’ strategy that people forget Microsoft is known for (See Microsoft reverses course or Internet Tidal Wave Memo).

Forget whether it will work or not, this Yahoo move communicates how competitive and aggressive Microsoft still is. If Google kicks Microsoft’s ass all over the next decade, it will be a bloody war all the way. Unlike IBM, Microsoft is not going to walk quietly to the sidelines of public attention; they’re going to go out swinging. So say what you will about the strategy, but in terms of moving to take control over the battleground, Microsoft has scored a victory: they’re in the headlines, for the first time in ages, for being on the prowl, while news of Google has fallen beneath the fold. With the paint still wet on their recent acquisition of DoubleClick, it’s hard for Google to complain loudly right now.

Ok, here’s the cynicism. All mergers suck. They really do. They rarely go well and when they do it’s only after 12-16 months of hand wringing and confusion among everyone involved on both sides (not to mention the costs of defections on principle). No sane person would ever choose to merge with another company that has overlapping product lines. It’s a move that is only conceivable from the landscape view provided by executive ivory towers. VPs can say all they want about not losing jobs, but everyone knows no VP would ever say “Yes. This merger means you will be fired 3 weeks from now! Run for the hills!” It just doesn’t go that way, ever. Being employed isn’t much of a prize anyway if the job that remains barely resembles the one you loved. Of course if you hate your job, or your project, then this could be opportunity time.

But on the whole I suspect the entire Windows Live division held in a collective cry of despair the day the merger was announced, in the same way the Microsoft Money team did in 1995. It’s hard to recover from that feeling of betrayal that comes from working hard for months, loyally following your leader’s commands, only to learn, as an aside, over coffee, that someone 5 levels above you had been scheming to buy a competitor, one of the targets on your well worn dartboard, all along. In the old Microsoft days it was the stock options that carried you through. The hallway talk was “We do what’s right for the company first” but I don’t know if that line is still heard, much less believed, anymore. In some ways merger talk is a reality test: is what I’ve made better than what we’re buying? And will the newly appointed mystery date VP agree? That kind of uncertainty can’t help but tank morale.

And now, optimism. As an orchestrator, an architect, a creator, this would be one of the greatest shopping sprees for intellectual property of the last 20 years. It will be a once in a lifetime treat to be the VP who gets to pick and choose among projects and people from two vast pools of ideas grown from very different gardens. Hand that task over to a Ray Ozzie, Chris Jones or Joe Belfiore, and, if you get everyone else sufficiently far out of their way, wondrous things are possible. I’d bet any of them, or perhaps a management star from Yahoo’s ranks, could inspire the best people from both companies to stick around, at least long enough to watch the first offspring rise above the merger mess, or, perhaps, go up in flames.

Commentary on NPR’s Marketplace, tonight (update)

March 17th, 2008

Joy of joys, I was asked to do a commentary on one my favorite shows. Marketplace, an NPR business news show, is running a story about the culture differences at Microsoft and Yahoo. Right after the story, there’s a short 2 minute commentary by yours truly (Prepare to cover your ears).

If you’re in Seattle, Marketplace airs on KUOW at 6:30pm today. You can listen to NPR live online here.

Once it’s online, I suspect sometime this week, I’ll post a follow up link.

It’s online now: transcript, summary, and audio.

The ideal designer & project manager

September 28th, 2006

pmdesign1.jpgOne question I’m often asked is what is the ideal designer? - I get this from managers or VPs in tech companies, trying to figure out what’s wrong with the relationship their managers / leaders have with the design staff.

Working with ideals is an interesting exercise: it reveals assumptions and forces opinion as there’s no right answer, and even if there were, this universe rarely grants ideals (at least to me). So here’s my staple answer on ideal roles, followed by some thoughts on reality.

The Ideal PM

The best PMs partner with design in a similiar way to their partnership with programmers. They collaborate (not dictate) with the designers/programmers, perhaps starting with their own seeds, or ones from the business folks, and then delegate as much of the engineering thinking and design thinking as they can. The ideal PM focuses on creating the best environment for all roles to do well: marketers, analysts, designers, testers, everyone. They carefully shift the environment, the power balance, and their direct involvement depending on the project goals, the talents involved, and how far along things are.

Instead of designing, PMs should first use their unique powers to co-ordinate their team with (or protect their team from) management, other project teams, budgets, star-charts, etc. Any other time spent designing should only be: in partnership with designers looking for collaboration/feedback, where designers don’t have time or when quality is low (just like they’d help out test, documentation, or whatever). A good PM is a leader and a results machine: willing to do anything to empower people on their team, including keeping their hands out of the design cookie jar (slap).

The ideal designer

Someone with many design talents and who is a natural thought leader on the team. They not only make wireframes and prototypes, but drive the thinking and tradeoffs behind them, comfortably evangalizing good ideas and staying near the center of important discussions. They are drivers in resolving design issues, solving problems, and making things happen, and people happily come to them for help with decisions. They are communicators and collaborators as much as idea generators, leading design ideas through engineering, marketing and other parts of the process. They negotiate with PMs on when to handoff design leadership and who is best able to represent a decision, a design or a problem to the rest of the team.

Designers should be the tiebreaker in design issues and be granted signifigant authority when ease of use, style and other design traits are important goals. The designer’s opinion on design matters should trump others, just as an engineer or marketer’s opinion would in certain situations. A good product designer earns these powers through the respect of everyone they interact with, as an intelligent, thoughtful, reliable teammate.

The common dysfunctions

I offer these not as inditements of entire disciplines - that’d be stupid. Instead, I can tell you that when there are problems, these are the most common things I’ve seen for PMs & Designers. If what follows pisses you off, find your counterpart: maybe PMs & Designers can at least bond in their flaming hatred for me.

(Hint: Put your lead suits on now)

Common PM dysfunctions

Many PMs know little about design, or worse, believe they know everything - the result is any good designer will be quickly frustrated and turned off by them. Arrogant PMs, particularly from tech-backgrounds, often have limited exposure to designers, or only mediocre, limited role / contracted ones, creating a self-fulfilling loop for their low expectations for design staff. Even if they come across a superstar design talent, the PM will be blind to it, misuse it, or frustrate it to the point that they are rendered mediocre, insanely bitter, or both.

PMs can be tyrants and empire builders (”Here comes Napoleon” is often heard just before PMs enter rooms), comically insecure about their power, who see designers as threats to their fragile sense of power.

Common designer dysfunctions

(Hint: Don’t touch that suit unless you’re adding another layer).

Many designers claim to want leadership roles, but as soon as there is a design tradeoff debate, or a tough business decision, moments where there is an interdisciplinary leadership vacumn that they are primed to fill, they retreat. When their team leaders need to be taught core design principles, brand fundamentals, or any basic concept, some designers sit in gloomy silence, prefering endlessly clever protests in private to stepping forward in mixed company as a true design leader. This kind of passive aggression confirms the team’s perception of designers as (bitter) specialists, and simultaneously reinforces the designer’s frustration with their environment.

Designers often have auteur sized egos without the auteur quality track record of shipped work (At least in the eyes of their team, if not in truth). This gap between how designers percieve their talents vs. how their team values their talents must narrow for relationships to improve, and the designer, in the minority, often has to compromise first but is unwilling to do so.

So how do you fix PM / design relations?

PMs have more responsibility for these issues: so I start there. They are often granted more authority than designers, and have broader responsibility - meaning it’s up to them to delegate authority to design or do whatever it takes to make designers effective. A good PM should see a designer or programmer as both a person and a resource, and their job is to maximize the value of that resource towards the goals. If a PM is honestly trying to make a designer as valuable as possible, collaboration becomes natural and tension evaporates. And if the designer reciprocates (does whatever it takes to help towards the goals), same thing.

But designers have to take risks with their roles - if they want more power or influence that only comes with asking for bigger challenges and delivering: something they have to push for on their own (In old-school Microsoft parlance, you have to step up). These changes make designers feel vulnerable, but growth requires moving out of comfort zones.
pmdesign2.jpg

In groups with no history (or a bloody one) of pm/design relations, it often takes a pilot effort: pick your most compatible pairing of a PM and a designer, define a new set of ground rules, and give them the cover-fire and resources (by their definition) to run with it. In a month when they can show kick-ass results, highlight them to the rest of the organization as the model to emulate. You need local examples of the new relationship working for people with intrenched opinions to change their minds. (Often you need to pick a trio of PM/dev/design for the pilot to work).

Reward models for Designers & PMs

The Pavlovian answer to all these problems is how the senior manager overseeing everyone rewards PM/designer behavior. If designers are rewarded for stepping up and being visible, they’ll do it more often. If you give kudos to the PM/designer pairings that collaborate best, more people will emulate them. So moving a team closer to ideals has more to do with what behavior is rewarded (promotions, raises, kudos, yachts, mansions, etc.) than what’s said or written down. Writing role definition documents is a waste of time if not tied to the core reward system.

One tricky pattern at many software companies (Microsoft included) is how people are rewarded for features: new features, big features, it’s features that drive how visible people are in their organization. (This is the true reason for bloat: people know it’s bad design, but the system rewards it, so someone always does it). To give designers more power in these environments demands shifting the PM reward structure away from feature design, and towards team building & team results, a difficult culture shift.

Notes and caveats

  • Since ideal people are rare, the best you can often do is approximate with a team. If you have 3 or 4 PMs who in conjuction play the roles, you have a virtually ideal situation. In reality this is a better way to use these idealizations that trying to hire perfect people.
  • Often it’s the lead position (lead designer / lead PM) that is closest to the ideal in the role that they play: using their own talents, and the talents of their reports, they are most accountable for using the resources in the best way possible.
  • It’s synergy at the manager levels that makes all the difference. If the overall project manager is sympatico with the most senior design manager, they’ll naturally pave the way for similiarly healthy relationships all the way down. But if they don’t, that gap will cause all of the organizations problems. Until they admit this and solve it, progress is uphill, on ice, in the dark, naked, while chased by rabid crampon wearing wolves.
  • There are many different kinds of design, which means many different relationships and roles. If I knew the details in a particular case (Feel free to offer one) I’d likely offer a modified set of ideals. The roles of visual, interaction, game, and web designers all create unique challenges.
  • Where is usability / user assitance / marketing / VP / me in all this? Hey, it’s just a blog post - can’t cover everybody. If you raise entertaining complaints in the comments, odds go up I’ll write about your favorite role pairing next time.

The Office sitcom meets Microsoft

August 28th, 2006

If you like the original british series w/David Brent, you’ll dig this:

Part1 and Part2

(link from Ario, Rbanks)

Replacing the desktop (not yet)

June 23rd, 2006

bumptop.jpgEvery so often the urge surfaces to replace parts of GUI, like Menus, toolbars and the desktop. This popular demo of BumpTop, from the U of Toronto, goes after the desktop.

First, some history: Back on IE4 in 1996 and again on Neptune (and here) in 1999 we brainstormed, prototyped and evaluated all kinds of radical re-inventions of the desktop (and GUI systems). For a time it was our mission, and we tried, read, played with, or prototyped just about everything that had been done. The conclusion (at least mine): The desktop is a ghetto. People spend so little time there during their day that reinvention doesn’t buy you much.

Certainly not enough to deal with re-learning basic tasks. Unless your reinvention carries over to replace File.Open dialogs and their bretheren too, it’s a low mileage revolution. (Not to mention how you get web-apps to follow your new models too). Especially these days with better search and big storage, people don’t suffer much from their messy, poorly organized desktops. Any UI problems there are noise compared to, say, fighting with web-based e-mail apps or on-line banking sites.

One perenial mistake we made in the Windows group was thinking of System UI (Toolbars, desktops, file folders) as a primary place. We spent so much time trying to build the system as a good experience, when the best thing we could have done would have been to get out of the way (admitidly harder than it sounds). Even then, as now, it’s the web and apps that get 90% of people’s time in any OS.

Now, Bumptop: This is fine research work and a great demo. They got an amazing number of details and subtlties right. It is the desktop metaphor to the max: you can shuffle, flip-through, scale, and crumple, just like things on your real desktop.

It’s certainly cool, but what difference does it all make? It’d be easy to run a baseline usability study, and compare human performance with Bumptop vs. Mac or Windows (A note to anyone else doing other GUI reinventions). Does all the visualization and pile manipulation speed finding things? For newbies or for experts? Who knows, but it’d be easy to find out and would cut the hype.

Even if it does - how much time a day do you spend organizing stuff into folders? If you’re like me, as little as possible. I clean things up when it gets too messy, but generally I avoid my desktop, or any file/folder/maintance, as much as possible.

If you do watch the video and get bored, skip to 3:00 in - more advanced manipulations including stuff I hadn’t seen before. If this stuff floats your boat, check out the Data mountain project from MSR, or Maya’s DEC project. There are tons of other visualization projects from the last 2 decades, but I’m too lazy to dig them all up for this post :)

(And now, since it’s 3pm in the peak of summer in Seattle, I’m going to get as far away from desktops as possible, and go outside to play with the dog - you should too).

Tales of Vista development at MSFT

June 18th, 2006

An interesting opinion on Vista’s project management issues from a former development manager on the Vista team (now a manager on the Tablet PC team at Microsoft).

It’s worth a read, is better informed than my outsider opinion, with references to action vs. results management, Too many cooks, Broken windows theory, opnions on Line of code measurements, etc. One favorite quote from his essay:

After months of hearing of how a certain influential team in Windows was going to cause the Vista release to slip, I, full of abstract self-righteous misgivings as a stockholder, had at last the chance to speak with two of the team’s key managers, asking them how they could be so, please excuse the term, I don’t mean its value laden connotation, ignorant as to proper estimation of software schedules.

Turns out they’re actually great project managers. They knew months in advance that the schedule would never work. So they told their VP. And he, possibly influenced by one too many instances where engineering re-routes power to the warp core, thus completing the heretofore impossible six-hour task in a mere three, summarily sent the managers back to “figure out how to make it work.” The managers re-estimated, nipped and tucked, liposuctioned, did everything short of a lobotomy — and still did not have a schedule that fit. The VP was not pleased.

“You’re smart people. Find a way!” This went back and forth for weeks, whereupon the intrepid managers finally understood how to get past the dilemma. They simply stopped telling the truth. “Sure, everything fits. We cut and cut, and here we are. Vista by August or bust. You got it, boss.”

Note: I had to set font size down in Firefox (Ctrl -) to read this without wanting to bash my monitor in.

(From metafilter)

The victimization ratio

April 6th, 2006

Interesting, if cynical, post over at next-microsoft. He mentions part of his criteria for chosing a job is how much power he would have to solve problems that impact him.

Basically the idea is this (a now corrected paraphrase of his post):

A = Number of problems you see
B = Number of Problems you don’t have the power to solve
B / A = Victimization ratio.

So if you work in an environment where you can point out 10 problems, but are only capable/empowered to solve 4 of them (so 6 you are powerless on), your victimization ratio is 6 / 10 = 60%

I think this should be modified to include C) problems you can get someone else to solve for you. If you have a good manager, or even a good team of peers or reports, they may have the power to solve problems that you can’t.

I’d argue that a good manager solves problems for their team all the time that the team doesn’t have the power to solve on their own (e.g. poltical/upper management issues).

Then of course there’s D - Problems that initially you don’t have the power to solve, but can obtain if you ask for it, fight for it, or prove you’re worthy of. There’s going to be a trend line for D - how easy is it to demonstrate you’re worthy of more, and how fast is it granted to you? I think that’s more important than how much you start with.

I’d invert the value and call it The empowerment ratio. And call D the rate of empowerment.

Full article - The victimization ratio

The Vista saga: an opinion

March 28th, 2006

VistaThe announcement of the Vista delays has sparked a new round of debates about what’s going on at Microsoft. The mailbox has been full of questions for me on the subject - so here’s some insights from a former employee (’94-2003) and manager in the Windows division.

For sanity - I’m an independent and this is not an apology, rant nor inside scoup. Instead it’s commentary from a management author on what’s been said and what’s going on.

  • Centralized authority and MSFT culture. The most comical misperception about Microsoft is the management style - everyone think’s it’s a rigid hierarchy, when it’s mostly a consensus driven place. Everyone gets an opinion and senior managers are often more skilled at consensus management than leading teams. If there’s any one thing I’d point to for large failing projects is lack of successful central authority - With a project in trouble I’d move to centralize power in a smaller number of people and free them to run with the ball. The rub is that the culture doesn’t support this well - people still want a consensus mentality (something born of small team and start-up culture), they want to own their slice, even when it’s contributing to driving projects into the ground (or at least mediocrity). It’s in the fiber of the company and it’s hard to change.
  • Talk is cheap. Every time I read rants about gutting Windows, firing all the VPs or making Windows open source I have one comment: I don’t believe you’d do it if it were your job to manage Windows. As easy as it is to yell orders from off the boat, I doubt most people, if given the helm, would put an $8 billion machine at risk. Certainly not now, as it would mean another 2 years of development. Besides, no one wants to be the one that tanked one of the greatest franchises in technological history (regardless of how that franchise was built). Even if big, bold moves are in order - I doubt most of us would have the guts to take those risks if we were personally accountable for the results. It’s a classic innovator’s dilemma situation. A better gripe is how the franchise hasn’t been managed on a steady progressive course, given how many possibilites there are for making things better without taking radical moves.
  • It’s never just one thing. It’s fun and convenient to chalk up project problems to one issue. “The VPs are idiots - fire them all!” or “they were too ambitous” but there’s rarely one reason (Nothing drives faith in the easy answer more than frustration). Most of the time there are several factors that conspire together, especially if it’s a large project with large goals. There are often successful sub-teams working inside most large, problematic projects (And some are speaking out over at mini-microsoft). As a consultant, understanding (and fixing) projects involves finding the factors and accouting for them without tanking the parts that work well. There’s rarely a single move that saves the day and any problem that took months to develop is not going to be solved in a hour.
  • A slip is infinitely better than a panned product. With a slip, even 6 months, people will cry and scream but the world will not end. However, with a bad release, like Windows 98ME, Bob or Netscape 5, the world just might fall on you. So while a series of slips shouldn’t inspire confidence, it does mean there is a sane person somwhere in the organization with their hands at the controls. The Vista news has been mostly negative, and no competitor has tried to capitalize on it, meaning a slip has little competitive risk.
  • However, the door is open for competitors . The bad Vista PR over the last year has made a window - Linux, Firefox and Red Hat should be doing something: a viral ad, a marketing campaign, anything. But they’ve been awfully quiet and I don’t understand why. I think this is the more interesting story than what’s going on in Redmond. The MSFT Windows multi-slip ship cycle is an old (perhaps sad) story, but the silence on the battlefront deserves more attention.
  • Microsoft’s PR and public management of the Vista project has been reactive and weak. I’ve never thought PR and marketing were well directed by executives (well funded, yes, but well managed or empowered, no). Many announcements and launches were messaged in the blandest, most generic ways possible (Win95 and X-box the most notable exceptions). Microsoft is inherently a conservative company (in strategy not tactics) and its always shown in its advertisements and approach to PR. For all the stereotyping of Microsoft as a great marketing company, I never saw it: Nike, Intel and Apple are all dramatically better and amplify the value of their product lines. Vista’s failures to date are more dramatic from a PR and messaging perspective than anything else. They’ve failed to articluate a value proposition (even if invented), and to bring a positive meme around the release to match or compensate for the litany of negative announcements and setbacks. The greatest failure of the project to date isn’t technological or managerial - it’s PR and messaging. A private train wreck is one thing, a public one is another.
  • Windows is a bear. Much of the franchise has been based on backward compatibility and some things that should be improved in the abstract can hurt the product line - it’s a trap any successful platform faces eventually (Just look at HTML or javascript). People write code to your bugs or inconsistencies, and when you come back to fix them you realize you’ll do more damage to them than good - a quality inversion. I don’t justify how the product got where it is - but here it is. Deciding what to do in any direction is strategically and technically complicated - this shouldn’t mute the complaints of unhappy customers, but it should be noted by anyone confident they can do a better job. Quality inversions surface in any project successful enough to see a version 5, or in Window’s case, version 8 (Win 1-3, Win95, Win 98, Win 2000, Win XP, Vista).
  • Sinofsky is an inspired move. The MSFT culture, historically, is heavily polarized between Windows and Office. In my day Windows were the smart-ass cowboys who liked risks and breaking rules - not surprisingly Windows had a history of confused early projects that came together only on the home stretch. Office (again, in my day) were stereotypically smart, reliable, consistent A students, who won through plans more than passion. Sinofsky (formerly the Senior VP of Office, now VP of Windows) is the first major attempt I know of to bridge those philosophical and management differences: there’s something to be learned in both directions.

Me, Microsoft and Digg.com

January 26th, 2006

One day this week, I think by accident, an essay of mine appeared on digg.com’s home page. The essay was “Why I left Microsoft“, something I wrote nearly a year ago. A big wave of traffic ensued, and then, the flame mail :)

The problem was this: I wrote the essay from my point of view: Why I left Microsoft, which is more about me and my life than about Microsoft the company. Ordinarily, who cares? But when a major site like digg lists a link to “Why I left Microsoft”, everyone naturally expects a bunch of fun insider information (and dirt) about what’s going on in the company. And when the web doesn’t get what it expects, well, flames and snideness ensue (as you’ll find if you skim the digg.com comments).

To make ammends I’m glad to write about Microsoft the company. I did write a short google/MSFT comparison, but when do you want to know? There are plenty of books and sources for insider information for those than want it.

Leave comments here - and I’ll write a follow up called “Looking at Microsoft” more in line with what folks wanted to read in the first place.

(And thanks to all that had nice things to say about the essay - appreciated that)

Best questions from the Microsoft talk

December 8th, 2005

Had about 120 people yesterday - and was thrilled to see some familiar faces. It’s always good to speak at Microsoft: the audience is always smart and likes to laugh. Here’s some of the good Q&A, from memory, from my talk on why smart people defend bad ideas:

What do you do if your boss is an idiot? Sadly, not much. If they really have some kind of cognitive disability nothing you can do can change that. But you can always look for points of leverage. Who are the smart people who work for your boss that have your bosses ear? How do they influence him? What issues is he smarter about that others and how do you play to his strengths but work independently on areas he’s weak on? And lastly, there are worse thngs than being stupid. Traits like trust, clarity, commitment and leadership skill are mostly orthogonal to intellect. A slow person who listens to the right people might make a better manager than bright person who ignores everyone.

How do you handle a manager that has difficultly making priority decisions? . Take on the burden of setting the plate for them. What can you do to make priority decision easier? This is a very generous form of managing up: where you define for your boss what you need from them to succeed. In this case, you’re going further and doing some of their work for them in order to make your work possible. If that burden is too large, look for other people who work for your manager who suffer as much as you do. You can partner up and set the table together. Also, know that prioritization is the single most important things managers of large teams do. If your manager isn’t doing it well, be worried.

What do you do in a group that doesn’t like to debate ideas? Some people have stigmas about debate: they don’t allow criticism or critique in fear of people feeling hurt. This usually sucks and represents fear of ideas an inability to seperate someone’s ideas from their identity: a death knell for creative thinking. However, in all groups, ideas are debated, just not out in the open. If debates are verbotten in meetings, look to the offices and cubicles. Bring your ideas to people one on one and invite people to come to you.

Why are copouts like ‘We don’t have time’ and ‘This is the way we did it last time? The audience and I discussed many reasons why these statements are problematic: They’re copouts and don’t represent thinking, they put decisions into unquestionable boxes, they imply a we vs. you dynamic which can bully question askers into submission. We agreed that heuristics like these are often right, and are fast to use, but also agreed that there must be a way to over-ride them and force real thinking to take place.

If you were there (or not) and had other questions, glad to answer ‘em here.

Google’s 10 rules compared to Microsoft

December 6th, 2005

Microsoft and GoogleMSNBC posted Google: Ten golden rules by Google’s CEO Eric Schmidt, on how Google manages their knowledge worker staff.

I know many people that work at both Google and Microsoft, and I’m sure this will be upsetting to all of them: the spirit of nearly all these rules are shared by both companies.

Having spent time at Google, I know it’s a special place. There are many things about their environment that are very different from Microsoft.

However Schmidt’s MSNBC piece has little to do with what those things are. Here’s a critique on how similiar this list of Google’s CEO’s rules are to my recollections of Microsoft’s approach.

  • Hire by committee. The article suggests (and I’ve been told) Google requires unanimous approval. Everyone you talk to must say yes. Microsoft’s bar is set by the team maanger. They expect a majority, but rarely require 100% consensus. But the basic format, you have intense real-problem focused interviews with 5-7 of your potential peers, each of whom gets to vote hire/no-hire, is the same.
  • Cater to their every need. In the early 1990s Microsoft formalized many of the fringe benefits some software companies gave their employees. Private offices with windows. Free soda. Good and cheap food. Showers in the parking lots. Massages during crunch time. Health club membership. Discounts at museums. Mega-flex time (just get your stuff done, we don’t care when you’re here, or for how long). Today there’s no comparison: Google is still small enough to do things MSFT never did, and currently can’t afford. But the attitude is the same: it’s the level of execution that’s different. It will be harder for Google to maintain those costs as the company grows and the rate of growth slows (It may take awhile, but it will happen): a challenge Microsoft is still dealing with.
  • Pack them in. Gates always believed that co-location was critical to getting work done with others, which matches Schmidt’s beliefs. Unlike Intel, a company that distributes it’s offices across the world, most of Microsoft’s core development teams are within walking distance of each other. Microsoft stops at the office level: Gates always believed that programmers need private spaces to be productive, whereas Google believes in shared spaces. But the core philosophy of easy access is shared. Microsoft does have some shared space teams, but it’s not the standard.
  • Eat your own dogfood . I doubt Microsoft invented the term, but they certainly popularized it in the 90s. This has always been a core value at Microsoft, and it’s been documented in various books about MSFT development practices. Everyone, from VPs to programmers are asked, begged, bribed, and cajoled into using early and experimental builds of new software. The problem eventually becomes this: how many things can you dogfood successfully at the same time?
  • Encourage creativity. Is there a CEO that would say they discourage creativity? Google wins here easily, as the 20% side project rule is a formalized and their campus is built for creative stimulation (unlike Microsoft’s relentless architectural repitition and squareness). But in my time at Microsoft (94-2003) side projects always happened - the difference was that it was up to my manager and I to negotiate what they’d be: I couldn’t argue for them on the basis of a promise the CEO made about encouraging creativity.
  • Strive to reach consensus. Microsoft is the poster child of consensus. For anyone that’s been a manager there, it’s well known that rough consensus is a necessary condition for many senior level decisions. This has become a bottleneck for many groups, as their size makes consensus management a painful and often self-defeating process (A fact that makes many of mini-Microsoft ’s comments valid. I’m waiting for the mini-google to arrive). But the point is: both Microsoft and Google have management philosophies based on the value of consensus.
  • Don’t be evil. Definitely differences here. First, I never got a “Be evil” memo at Microsoft. The message I did get was this: WIN. There is a difference. While trying to WIN won’t get you sainthood, it’s philosophically indifferent: it’s about a result. Many things Microsoft was criticized for came from someone trying to WIN in the short term, without recognizing the long term consequences of how they won. Call it stupid, selfish or immature, but evil often (but not always) seemed a stretch. Google’s choice to make a public philosophical stance is noble, and puts the rest of the business world in cowardly relief (Although, where is the company that says “We actually do GOOD?”) But the stance is rife with problems. Any time you in are in a zero-sum competition, and WIN, even if you do so graciously, there will often be someone who feels they lost who will point a finger at you and say “You did evil to me”. Watching a major corporation manage a philosophical, moral position is fascinating, and definitely something Microsoft has never done.
  • Data driven decisions. Is there anywhere in the tech-sector that isn’t data driven at the management level? I happen to think we’ve gone too far, and abuse data left and right. But it’s well documented that compaines including Microsoft, Amazon.com and Google are all intensely data driven.
  • Communicate effectively. All hands meetings and beer Fridays are industry and bay area staples, as is the occurance of executives saying “we should communicate effectively with each other”. Is there anyone out there that advocates bad communication? Holds miscommunication rallies? I think the problem with this entry, and the list, is it’s a platitude. The notion of good communication is universal: but the sucessful practice of it is rare. Closing that gap is where the magic is at.

In Summary: there’s little motivation for the CEO of a leading company to reveal what he thinks the true secrets or powerful rules are. There’s more to lose than to gain. But this piece, as fluffy as it is, doesn’t say much about management than anyone paying attention didn’t already know.


You're reading scottberkun.com, home of tasty essays. All rights reserved unless noted. You can subscribe here (RSS ).
If you're not sure how to feel now that you're at the footer, joy is free and recommended.