While lobbying for some cross-team feature political support in one of the prettiest cafes on campus (34, what a view) I noticed a setup for a presentation. I wandered down and saw it was for Bob Herbold, swinging through campus to talk about his book, The Fiefdom Syndrome. Free chips and candy bars? Plop.
So Mr. Herbold begins a very nice presentation about how business groups grow and then stifle progress by continuing to produce work and process to justify their ranks. These groups are especially prone to sticking with old methods that require lots of process intensive labor, vs. switching to new or disruptive approaches that promise to save time, money, and require less people. Lots of real world examples, some even based on his time a Microsoft bustin' up stagnant groups. I was so intrigued I ended up laying down some cash and reading the book. More on that below. First, let's have the dessert of this post.
During the Q&A, a young lady asked Mr. Herbold how all of his principles and insight would apply to present-day Microsoft. Bob took a pause and showed restraint mixed with reluctance. He apologized for his answer being vague, but basically he said, "Microsoft has hired lots of people since 2000. It's unclear to me what their level of focus is."
My inner self's eyes sproinged all big and anime and clasped its hands to a throbbing heart, sighing, "I'm in luuv puppy luv!" But then Bob stopped there and didn't take the assessment much beyond its promising beginning. Tease.
So Mr. Herbold isn't outright calling for massive layoffs and reorganizations at Microsoft, but his book does cover how you have to look out for parts of your organization that grow and then put intensive effort in to justify their current size and even try to grow more. Much like a zealous GM or VP out to create busy features or absorb other teams when the right thing to do is actually downsize their team to something manageable (or to break-up the team entirely).
Here's one of the biggest so-common-sense-it's-not-common-sense observations I got out of the book: smart people figure out quickly how to succeed and be rewarded in their group. Chapter two is all about human nature. People don't typically get rewarded by being disruptive pains in the ass but rather getting along to get along and further up the compensation ladder.
Sounds simple. Sure enough, if you are rewarding people for demonstrating that they excel at process excellence then, well, Hell, forget if you actually ship features. Look at all these pretty, beguiling graphs about promising features! And fetch me a crop of dithering middle managers! If you openly reward and promote people for killing work by bemoaning the risk and the testing cost and localization impact of each feature and interrogating a DCR as if it were Dan Brown shackled in-front of a wild-eyed, hot-poker wielding Pope, well, everyone is going to grab pitchforks and jump on that "No can do! No can ship!" bandwagon.
It makes me think of how many feature meetings I've had and what a small percent of those features have actually ever shipped. Not that every feature is a good idea, but it's damn near wake-worthy sometimes for a feature to actually get out into shipping bits. Que Eeyore: "Oh no. Now we have to support it. I suppose a hotfix request will come in any moment now..."
Anyway. Other interesting bits I'd like to call-out in the book...
Fiefdoms are bad. They result in stifled organizations that freeze up and let competitors breeze on by. They lead to inefficiency and ineffectiveness, reducing market share and profitability. They breed mediocrity.
The folks in charge of the fiefdoms jealously guard their high-performers, not letting other groups know about the people they value most, less that fiefdom lose a key contributor (to whom they might give so-so feedback to). Folks gravitate towards a comfort zone and stridently maintain the status quo. Once another leaner, meaner innovative group or competitor comes along, the fiefdom plain can't compete and while it might save a little bit of time from obsolescence via plain mean business or political tactics, the folks who snuggled down into the comfort zone and jellified themselves to mediocrity usually end up out of a job.
I like this observations (pg. 82 [hardback]): "If you leave people in the same job for too long and allow them to become too comfortable, without encouraging them to grow and learn, they lose the capability to renew themselves and think about alternative ways to get the work done. They become a liability for the company rather than an asset."
In chapter four, he recounts a company that started measuring "good" and "bad" attrition. I'm pretty sure he means Microsoft because we started that given all the good people leaving the company and all the bad clunkers we really need to fire but don't seem to have the gumption to. Usually when Bob talks about Microsoft he calls us out specifically. Not here. Also in that chapter he mentions the "360 assessment." I think everyone who has been at Microsoft for five years should get a lightweight one of those as a reality check.
Interesting at the beginning of chapter five where Bob mentions all the points of the company where it "touches" customers and consumers that he doesn't mention product support (e.g., PSS). Curious. Given the recent horror stories coming out of our gutted support group, I guess you can see an executive leadership pattern of disdain for support ("Oh, let them Google-it, I mean, Butter-fly it - well - MSN search it - grr, you know what I mean.").
Oh, lowlytech.com, how are things nowadays?
I'm back to luuv in chapter six on the section "Fiefdoms and Six Sigma." When you're dealing with people shooting you with process arrows and telling you all the reasons why we can't ship a feature, it's always nice to have a quote like "'Why didn't you tell me that we weren't interested in exciting the customer, that we're interested only in making this thing risk-free and cheap?'" ready to go. Oh, dang, that could be applied to so many circumstances here. And this just feels like Courvoisier slipping around my cortex when I read it, "The mistake the CEO made is that he created the perception that the company's primary objective was excellence in Six Sigma as opposed to excellence with their customers."
Reorganization plays a part not only in bustin' fiefdoms but also ensuring that they never form. I've got notes all over chapter eight, "Fostering Creativity," and I could quote it to an extent that I'd feel guilty of retyping most of the chapter. Oh, but there are some goodies in here, like: "What fiefdoms do is constantly load people down with excess training and communication, handicapping them with the mediocrity that the group has become comfortable with. Strong performers tend to see what's going on pretty quickly and work to get out of that environment." Ba'zing! Lost any strong performers lately? And how much process do you have to deal with given just three or five years ago? Lots of videos to watch as part of complying?
Section five of this chapter is "Don't overcomplicate the process" and it's super-duper great. As is the next, "Focus on customer needs, not meetings and memos."
- "...you can't develop a process to generate innovation."
- "[Process meetings] were eating up big chunks of time."
- "...the focus of the discussion has to be on understanding consumers, probing for areas of consumer dissatisfaction, and looking for areas where you can surprise consumers with new capabilities."
In the end: any process you have needs to have its end result around generating something great for your consumers. If your process doesn't benefit your customer, what the hell good is it? (my, ah, paraphrasing.)
Curious note about BillG (pg. 72): "Bill Gates constantly looks for problems. He looks at everything that happens on a day-to-day basis and asks what Microsoft needs to improve upon." I'd love to know some of his answers to this as of late. Because the way things are looking, he must be considering some damn peculiar questions.
Do I recommend the book? Yes, if you're out to bust some fiefdoms up. There is lots of damning measuring sticks you can pull out from this book, and probably it has a tad more cachet than most business books given Mr. Herbold's personal association with the company. What are some of the lessons I think that applies to Microsoft and its product divisions:
- We need reorganization bad. And we need to reorganize into smaller, leaner, meaner groups.
- Process that doesn't briefly answer the question "How does this benefit our customer" has to be dropped.
- Get rid of your middle managers. Okay, I slipped that one in. But, like Christine Gregoire saw, if you have a bunch of middle managers, you probably have a bunch of bureaucratic process requiring their presence to keep shuffling information around. Get rid of them and the process at the same time. Gov. Gregoire has 1000 middle manager positions up for elimination. I bet we can meet that!
- Strong performers get screwed if they end up in a fiefdom. Your bosses don't sing your praises, worried that someone might try to steal you away to their group. If you've read this far (wow!) one thing you need to do when you show up at work is assess if you're stuck in a fiefdom. If so, and you're not able to break it apart, get out. Just imagine the voice in the Amityville house has finally managed to whisper in your ear, "Get out!"
- You need to switch jobs and responsibilities before you get comfortable doing what you're doing and start down a one-way path of career atrophy. Microsoft used to force this through reorganizations. But people are snuggling down, like ticks.
- And going back to Mr. Herbold's hesitant observation during his presentation: yes, Microsoft has indeed hired a lot of people since the year 2000 and their focus, and their purpose, is very unclear. Would we have shipped Longhorn any later with less people? Nope. Probably sooner because we wouldn't have dreamed of doing all that dumb-ass CLR-based stuff that ended up being cut. Does Office need all those people to add a reading view to Word? We can get by with so many less people, because at the end of the day, it's the super contributors responsible for most of the features that get designed, implemented, tested, shipped, marketed, sold, and supported.
At least roll the payroll numbers back to year 2000 levels. Let Gretchen focus more on firing hiring managers vs. having to rant about their spoiled, whiny ways. Let researchers go back to working for colleges and mentoring future generations of software developers. And bust the stagnant mediocrity we've snuggled into and get out there and start wowing consumers with delivering what they want, need, and didn't even know could be done.
