June 23, 2005
10 Slightly Unusual Ideas to Mildly Perturb MicrosoftA few months ago Mini-Microsoft talked about the Bill Gates think week paper entitled "10 Crazy Ideas to Shake Up Microsoft". Dare Obasanjo recently discussed the paper and said that the list "succintly summarizes the major problems facing folks trying to get stuff done at Microsoft today".
So I finally read the paper today, and I have to say I was massively underwhelmed. As Mini-Microsoft already revealed, the 10 ideas are:
- Schedule Unscheduled Time into Performance Reviews
- "Break Up" the Company
- Encourage Loose but Prominent Couplings
- Exile and Empower Incubation Projects
- Offer Super-exponential Rewards
- Offer Different Risk-Reward Compensation Profiles
- Cut Back on Bureaucracy
- Review Cost Cutting
- Reduce Headcount on Large Dev Projects
- Eliminate Exec Reviews
My comments on these:
- This is a legitimately interesting idea (the suggestion is to take Google's idea of 20% free time and apply it to Microsoft). It's a complete ripoff from our current biggest competitor, but that doesn't mean we shouldn't do it.
- This is nothing new; it's a common suggestion for big companies (encourage internal autonomy). Microsoft already has pushed P&L respnsibility down to the 7 product units and beyond; this suggestion would not have helped Longhorn ship any sooner.
- Microsoft already does this; that's why all the examples in the paper are from Microsoft. Is the point that integrating Office was a good idea? You're right, integrating Office was a good idea. To the extent that this point doesn't contradict the previous one (about 50%, roughly), it's already known.
- This is a good idea, but again I don't think it's a crazy idea, or a new idea.
- Microsoft already does this.
- I think this is an actively bad idea. If people want to take a huge risk and get paid in equity rather than salary, they should go do a startup.
- Sounds great. Let's make crime illegal while we're at it. The honest-to-god suggestion here is to add more bureaucracy to police the existing bureaucracy.
- This kind of suggestion always puzzles me. Do people really think that executives cut costs willy-nilly without thinking of the effect on employees? Do they really think they cut towel service and then after-the-fact say, "Gee, we never realized that this might upset someone?" Do you think they limit supplies to the first floor without realizing that this requires employees on other floors to walk down to get supplies? Look, you may agree or disagree with decisions like these--but the notion that these ideas are not fully considered before being implemented is ridiculous.
- Ah yes. This assumes that the corollary to the Mythical Man Month rule that "Adding more people to a late project makes it ship later" must be "Removing people from a project that is late makes it ship earlier." Every project I know is perennially understaffed. Now, there is a good idea buried in there, which is that management should be judged on their ability to deliver on time.
- The answer here should not be to eliminate executive reviews. The answer should be to eliminate executives.
So I count this as "1.5 Actually Interesting Ideas, 2 Ideas We Already Know, 2 Things We Already Do, 3 Silly Ideas, and 1.5 Bad Idea." Not as snappy a title, but IMHO more accurate.
I'm not saying Microsoft doesn't have problems; the company has big problems. I just don't see this paper addressing them, and I doubt it would make Bill Gates do much except roll his eyes. Microsoft has antitrust issues, it has trouble hiring the people it wants, it already makes so much money it is hard to grow the stock. The company does have a long-running "eyes bigger than stomach" problem in which it continuously tries to tackle big projects in one fell swoop; the think week paper hints at this in terms of cross-group dependencies, but it's not just that, it's the sheer size of what individual groups accomplish. Probably this is because the company overvalues failure as a learning experience, but who knows...my point is that the problems Microsoft faces are very hard. If they were easy problems that could be fixed in 10 simple steps, they would have been fixed.
If you want crazy ideas, then propose some really crazy ideas. I can think of a few:
- Create two teams to work on the same project and let them race.
- Rotate employees on a team through the lead position.
- Allow any dev in the company to modify the source code of any project.
- Make our project schedules public from the start.
- Merge the dev and test teams on a project (everybody does both).
- Pay at 120% of the industry average.
- Release all of our source code (hey, had to throw that in there).
It's easy to sit there and get all goo-goo-eyed over what two people can accomplish in a month with no management oversight. But the reason two people can accomplish that in a month...is because it's two months of work. It's not Windows or Office.
Actually I just went to a talk today about a project going on inside Microsoft that trying to be progressive in how it goes about its business...and has at least one really good idea that should go in a thinkweek paper. But the talk was NDA, sorry! If you really want to know, come work for us. That'll help solve both of our problems.
Posted by AdamBa at June 23, 2005 10:26 PM
TrackBack URL for this entry:
"Do people really think that executives cut costs willy-nilly without thinking of the effect on employees?"
I think they underestimate them. I doubt the head of HR was expecting to leave quite so soon after implementing those changes, for example.
Posted by: Jonathan Hardwick at June 24, 2005 12:39 AM
"this suggestion would not have helped Longhorn ship any sooner."
Really? Longhorn took dependencies on SQL Server (WinFS) and DevDiv (WinFX). Do you seriously believe that without these dependencies LH couldn't have shipped faster?
If so, that seems like an indictment of the Windows org.
Posted by: Dare Obasanjo at June 24, 2005 05:33 AM
Jonathan: Well, there was the one change that was badly communicated by HR. But in general...sure people complained about the towel service FOR A LITTLE WHILE. Did anyone actually quit over the towel service (who knows)? What if the stock went up a quarter of a point because we impressed an analyst by cutting towels, was it worth it then? I'm not saying I have blind faith in our executives (far from it!) but this is not a big open-ended decision with lots of unclear variables, this is a pretty easy "it costs this and then this happens" choice and I'll trust them to consider those completely (even if I wouldn't have chosen to cut the towels--disagreeing with someone's decision is different from disagreeing with their decision-making).
Dare: Of course those were (in retrospect) bad decisions and Longhorn would have shipped earlier without them. But those technologies were already being developed in a different P&L (let alone from separate GMs or PUMs). So how does pushing decision-making further down help? This wasn't one VP saying "I own Longhorn and I own Avalon, smoosh." This was already a decision made by groups with their own autonomy. It just was a mistake (or an execution failure, or whatever).
If the argument is that you shouldn't take big dependencies on v1 components and you shouldn't try to do too much in one release...sure, often, but that's not what the paper was saying there.
Posted by: Adam Barr at June 24, 2005 06:10 AM
It would be much simplier if Microsoft just stops working on all products that exist only for compleatness and have never brought profit, nor somebody expects profit from them.
For not hurting costumers, open their source and let them support themselfs. Keep few teams to apply patches that are send back. Or even allow hire-an-coder or implement-a-feature-for-money basis.
MS can keep the crown jewels private.
(I know this won't happen, these projects exist only to oppress competition in case one of them is "The Next BIG thing")
Once I read (probably in slashdot) an very intersting comment. It compared corporations to countries. While the progress of the social and politic system forces masses (!) to have more control of the rulling party, the corporations are still following and strict top to bottom indisputable orders model.
As it seems from my POV the smartest people, these who actually build the products, are never involved in the big decisions that choose the fate of the company.
After reading some minisoftes, I came up with the next raw idea:
How about developers choosing the payment of their managers. Making the process bidirectional could bring balance.
(this also won't happen, these who have the power never surrender it without fight)
Posted by: Ivan at June 24, 2005 06:20 AM
Here's another crazy idea to add to your list:
Eliminate Program Managers
Think it through, it makes sense.
An -experienced, senior- developer can perform the tasks that a PM performs, and is motivated to perform them efficiently so they can get back to developing. A fluid engineering team organized around shipping products to their customers does not need a dedicated Program Management role. Program Managers are having an identity crisis because their role is unnecessary and overlaps others' skillsets.
The perfect team, in my opinion, is comprised of "leader" developers doing development, requirements/design/customer work, and testing of their code, "follower" developers doing development and testing of their code, and testers doing test development and testing of other peoples' code. The team is agile, responsive, more efficient, and focused on the quicked path to shipping.
Posted by: xyzzy at June 25, 2005 10:44 PM
I agree with a lot of what Adam is saying - the paper is fluff (I have to admit, I read two other papers and one was even worse than this one, something about "Lessons learnt from project x..").
**Merge the dev and test teams on a project**
Not so sure about the idea of having dev/test merge into one single team with each being able to accomplish the work of the other. I think that good testers aren't necessarily good coders and vice-versa. Testers should definitely be able to read dev code thats being checked in so that they can zero in on problems quicker and possibly even suggest fixes without having to blindly throw it over the fence to devs ("Hey its broken"). Also, I think it helps to have Dev and Test as two different teams because a little healthy competition between the two can help improve the work that each does.
**Pay at 120% of the industry average**
I'm not sure where we stand wrt to the industry standard but taking benefits into consideration, they are pretty goddamn good. I mean, even little things like the pro club membership or even your Passport Prime card/Flex pass/etc really make a difference if you stop and think about it?
**Eliminate Program Managers**
I think theres too many employees, period. Bloated teams are everywhere. But I'd say that I run into a lot of non-technical PM's who are in the position to make critical decisions that require technical skills.
Posted by: anonymous at June 27, 2005 12:37 AM
As we move towards more and more test automation, where devs are writing unit tests and testers are writing test harnesses, merging them could make sense. For example on Monad it might make sense. It wouldn't work on every team, certainly.
120% pay...well I said it was a crazy idea! But it's sort of like when attendance is dropping for your baseball team, you could try bringing in some high-paid stars to turn it around, hoping that the increased attendance would more than make up for it. It's more of a gamble, of course.
Eliminating PMs...that wasn't my idea. PMs came about for a reason. Actually if I had to recommend anything it would be merging PM back with marketing. Of course that would tend to exacerbate the "non-technical PM" issue.
Posted by: Adam Barr at June 27, 2005 03:31 PM
Merging dev and test would be a DISASTER. If this is done, there would be no quality control whatsoever, because everyone would be driven by the same (insane) schedule, and there'd only be time to write code, not test it. Then there's a problem of different priorities. Dev's goal is to develop a feature to the point where there are only a few bugs and he can forget about yet another steaming pile of horseshit that's now a part of the product. Tester's goal is to find as many bugs as he possibly can (testers are stack-ranked by bug counts sometimes) and make sure horseshit that developer has cheked in doesn't smell, so that customer thinks he has a high quality product. If you merge the two disciplines, you eliminate the sniff test.
Now the PMs, while I think eliminating them entirely would be a bad idea, firing about a half of these lazy handwaving mofos would only be good for the company I think.
Posted by: Anonymous at July 5, 2005 12:31 AM
I don't mean REMOVE test and make all the testers into devs. I mean take all the things dev has to do, and all the things test has to do, and assign those goals to one combined dev/test team. So that team is responsible for design, coding, BVTs, unit tests, etc. and has to figure out how to deliver all of that. Microsoft is moving from the STE to SDET title for testers, so put their money where their mouth is.
Posted by: Adam Barr at July 6, 2005 09:34 PM
I think the dev / test merge idea is interesting but I'm not sure if it's the best solution. I think a better solution would be to make test own the product code. Currently dev owns the code and test throws everything they've got at it. If instead test owned the code and was the gateway for dev to add or modify the code things would be very different. Test would force dev to deliver high quality and test would be forced to have to execute on delivering high quality & reliable test suites.
Posted by: anonymous at July 8, 2005 09:50 PM
I completely forgot about this post until Mini linked to it today. There are more comments here than I remember seeing.
I don't think the anonymous anti-dev-test-merge poster understands what testers do. As a tester I'd like to rebut:
". . . because everyone would be driven by the same (insane) schedule . . ."
We already are. Actually dev, test, and pm are all here to ship software. We're all working toward the same milestones on the same products. Ideally, all three disciplines can help one another out if one of them is in a crunch. It kinda works like that on my team.
". . . and there'd only be time to write code, not test it."
Nope. At least in Windows where I work devs are required to write unit tests. Experienced devs know where bugs can hide as well as (often better than) testers do and they're invaluable during test plan and test code reviews. Having devs who didn't write the code you're testing attend test reviews is also good idea.
"Dev's goal is to develop a feature to the point where there are only a few bugs and he can forget about yet another steaming pile of horseshit that's now a part of the product."
My name is Drew. If you're a dev and you ever hear of someone named Drew interviewing to be your tester, please do me a favor and paraphrase the above sentence to me. I promise to reward you with $50. Then I'll be on my way out the door, thank you.
"Tester's goal is to find as many bugs as he possibly can (testers are stack-ranked by bug counts sometimes) and make sure horseshit that developer has cheked in doesn't smell, so that customer thinks he has a high quality product."
Please tell me you're not a tester.
Unfortunately there have been times/places where testers have been ranked (at least partially) on their bugcounts. With a little thought, I think it should be obvious that many shallow bugs would be better than a few deep bugs in that situation. I haven't heard of any teams using this metric in years.
"If you merge the two disciplines, you eliminate the sniff test."
I don't even know how to react to that. I don't see how it follows from anything else you wrote even assuming I agreed with all of that hogwash. I would expect any technical employee of the company to be able to read a bug description and repro steps, install a private fix, and do a little smoke testing. I know a certain person who used to love to do that with crucial bugfixes when he was a pm lead (meaning certainly NOT a tester).
I'm not advocating merging the dev and test teams, though. I think it would damage too many dev egos. (meant tongue-in-cheek)
Posted by: Drew at July 25, 2005 11:27 PM