The .NET Sweatshop (v2) : management

Peanut Butter Jelly Time? (Part II)

SandyK — Wed, 27 Dec 2006 10:59:23 GMT

Following up on the Yahoo memo, I found it interesting to read the section regarding the effort level at Yahoo. I believe the larger your company grows, the harder it is to get everybody driving hard--especially at the levels of a startup. For as much as people love to lobby for the "startup mentality" at large companies, I think that's rare to get that to happen. I would love to tell my team to operate like a startup, but if my VP (or for that matter anyone up to Steve Ballmer & Bill Gates) hands down a mandate that we use a certain product, restrict a branding decision, or align with a corporate direction, I am obligated to push that direction down on my team. And by accepting these uber-decisions, the team knows that it answers to a higher authority. Startups don't have that. With the exception of the venture capitalists, the highest authority is usually sitting just down the hall or, in some cases, in the same room. No "blaming it on the man"--you are the man. That's empowering. Yahoo is a mature company and a random developer in Yahoo Mail eventually has to make sure he is aligned with Terry Semel and his band of merry executives, who, in turn, need to keep Wall Street happy. Sorry, but that's different than a couple of guys in a garage with a dream--no matter how much you encourage your team otherwise. Go ahead and try to convince him to work like it's a startup.

So as a manager for the world's largest software company, does that mean I'd accept anything less than a 100% effort from people on my team? Of course not. Occasionally, you spot people that are dogging it and I expect the managers on the team to call them out and suggest they look for more interesting employment if we can't keep them entertained (and that has happened in my career). Complacency is contagious and it's nice to nip that in the bud.

But what of those people ready to work, but lacking the motivation that is built-in to to startup's "do-or-die" culture? In other words, how do you maximize the effort at a large company? I think it's twofold. First is to "accentuate the positive": I think you need to focus on a separate set of incentives at play with a larger company, not the least of which revolve around the magnitude of the impact they can make. While the startup is exciting, 9 out of 10 startups fail (heck, I've failed once myself). Doing something at Microsoft is like doing it into a megaphone and the thrill of knowing your effort will be enjoyed by millions of people (which is what I can boast to my team) is pretty powerful as well. It's the difference between the effort an indie band makes trying to score a record deal and the effort that U2 makes during a sold out set at Madison Square Garden. Just because you've made it doesn't mean you can rest on your laurels--in fact, the expectations are higher. Nothing in the Yahoo memo suggested that the success they have had should hold them to a higher standard. It's as if they'd be better as the two Stanford PhD's who create a web directory. Embrace your success! Second is to eliminate the negative: while I can hope that they feel enough autonomy to let operate at a startup pace (complete with insane hours and the sense of being on a mission that makes the effort worth it) and feel that level of empowerment, I realize that it's foolish to set it as an expectation when I'm at a 70,000 person company. That's said, minimizing the impact of the rest of the company on the individual contributor, shielding them from the unnecessary garbage that often comes in. Only then do you get the empowerment and autonomy that creative people crave. That spurs effort. The delta between what comes from the team themselves and what reaches the customers should be minimal. That's empowering. Getting caught in the exec spin cycle of "tweak this, change that" cuts down on the empowerment. Of course, what, then, is the role of the "boss"?

The Yahoo memo did make mention of the bureaucracy facing their company and how ownership was split around the company in different disciplines (Engineering, Finance, Marketing, etc). With no clear ownership, execs were being forced to make decisions. My question is "which decisions?" In most cases, execs don't need to make decisions, but rather they need to assign who should make which decisions and stand behind those decision-makers (unless they are in strong disagreement, in which case, a discussion should occur). They should also ensure proper collaboration between the appropraite parties to come to compromises when necessary and arbitrate when no other solution can be reached. I like what Eric Schmidt at Google said about his role as CEO (I believe this came from the SF Chronicle, but I lost the link):

(Schmidt's) primary job is to run Google's numerous staff meetings. To get the most out of them, he relies on two philosophies. One is getting opinions from as many people as possible, particularly dissidents, under the theory that decisions are better when based on many viewpoints. Another is to set deadlines because, unless there's a reason to end an argument, people will continue to argue. He described a time when founders Sergey Brin and Larry Page were arguing violently about Internet browsers and software that had pitted them against one another in front of other managers during a meeting last year. After a while, Schmidt, who was also in the fight, put his foot down. He emptied the room and told the co-founders they were to reach an agreement by 6 p.m. because the dispute was confusing the staff. They resolved it by the next morning.

That's a powerful way to lead: ensure all avenues are reviewed, get the objections out of the way, and force the elimination of dangerous stalemates. Life is all about dissenting opinions, tradeoffs, and compromises and your ability to navigate effectively is the difference between success and failure. The exec should be a part of the debate and, when necessary, step up and make the decision. Yet it shouldn't be an in a vacuum, but rather the exact opposite. Empowerment isn't absolute authority, but rather an voice that will be heard loud and clear--particuarly as it relates to one's expertise. It's not consensus. It's not even necessarily a democracy where majority rules. It's a collaboration where the collective establish mutual respect and can generate something greater than a solo entity and the best ideas win. Imagine that...

Peanut Butter Jelly Time? (Part I)

SandyK — Thu, 21 Dec 2006 10:12:00 GMT

The shakeup at Yahoo is a fascinating reflection of the life and times of a tech company. Now many consider Yahoo a competitor to Microsoft and I have no interest in disparaging their company, but this is an interesting business case study and there is a lot of learn here from a strictly academic perspective. So ignore my MS bias and assume my statements are made from the perspective of a innocent bystander.

Seems like even before the shakeup, there'd been a lot of dissension over at Yahoo, which included an e-mail entitled "The Peanut Butter Manifesto" that came out last month. In it, a Yahoo senior exec called the company to task for (among other things) spreading themselves too thin across too many projects (losing focus) and pretty much giving a half-baked effort on their projects. He seemed to think the company lost its drive and was wallowing in their bloat. Interesting. There are two parts of the document that are interesting: the diversification of interests and the operational efficiency of a disenfranchised workforce. I've got a lot of thoughts on both, so I'll split them into two blog entries.

Judging the "Peanut Butter" effect as it relates to an overdiversification of business interests, it makes for an interesting debate. According to rumors that I recall floating around, Google is undergoing the same sort of internal scrutiny and recently shut down their Q&A service as a possible harbinger of things to come. While their success has been far greater than Yahoo, they are being critical about how they are execute on their charter. They also believe that they need to focus on the businesses that have the highest chance of success instead of the spaghetti approach of throwing a bunch of stuff against a wall and seeing what sticks. When Jack Welch was at GE, one was his most popular approaches to optimizing its success was to tell businesses "either you're #1, #2, or you will be #1 or #2 in an market within a couple of years. If not, out you go." Well, those might not have been his exact words, but you get the point. Welch was focused on markets that he could successfully compete in. For students of the BCG 2x2 matrix, he wanted to be a Star or a Cash Cow, but had no interest in the question mark or the dog. For those who have read Jim Collins' Good to Great, this sounds like the "Hedgehog" concept (fwiw, I really didn't like that book) in determining what you do best. With the Yahoo memo, there was a suggestion that they were complacent in being the question mark (high growth, low market share) and that was impeding their ability to succeed in their other businesses and hurting their overall corporate health. Some might suggest that Microsoft is in danger of doing the same thing.

I agree that simply getting into businesses for the sake of getting into the business is a bad idea. I also agree that you need to learn when to say no. But I also believe that there are some businesses that may take a while to incubate and you need to know where to preach patience and where to come quick. I look at other companies and wonder how their decisions are being perceived internally. eBay's decision to buy Skype shows a plan to diversify in a way that (in my mind) still doesn't quite align with their strategy to be the world's greatest flea market. Amazon's S3 play is a bold move that has nothing to do with retail. Are these good or bad? My instinct is to say "bad", but I've been too quick to judge in the past. I do recall chuckling when Apple came out with the iPod, thinking "what does the iMac company have to offer the gadget world? Here's another Newton..." Well, I was obviously wrong about that. Now, in retrospect, that was a great move by Apple. But wasn't that spreading the Peanut Butter a little bit? I have to admit that I like a lot of Yahoo's offerings. I think their foray into being a content company wasn't as flawed as people are trying to make it out to be in retrospect. The problem with bold, gutsy decisions is that you are a hero when they succeed (Steve Jobs and the iPod) and an idiot when they fail (John Sculley and the Newton)--and oftentimes, the result has as much to do with luck as with any specific aspect of the decision. For Microsoft, diversifying into enteprise computing has given them a growth engine that has been pivotal in the last several years. Building a home and retail presence with XBox and Zune is meant to give us something to hang their hat on for the next decade. To base Microsoft entirely on operating systems and productivity applications (the historical primary money makers) and cut all else would completely ignore the fact that you need to prepare for life after your core competency. Thank goodness Microsoft didn't give up on SQL and hopefully we'll be saying the same about Zune in a couple of years.

Again, I'm not suggesting haphazard business launches for the sake of letting workers do whatever the heck they please. But when I see things like Live Labs, I am excited, rather than pertubed, by what to bodes for Microsoft's future. Cutting businesses provides a short-term fix and does quench the Wall Street thirst, but be careful where that leads you in the long run...

Intrapreneurship and the Innovator's Dilemma

SandyK — Thu, 23 Nov 2006 01:39:00 GMT

Has anyone else noticed how much the word "innovation" gets tossed around lately. I think it has always been important in the technology industry where it is seen as the holy grail. We all aspire to be innovative and be called innovative. Personally, I've tried to stray from the word a little bit because it's like one of those catchy sayings that's lost its cool because everyone uses it. It's like how Eric (one of our developers) told me how once his mom said "What's up, dog?", he just couldn't use that phrase any more. But I will ignore my one word semi-boycott for the purposes of this blog because I've been faced with a fascinating dilemma.

So, if you've read some of the blogs from our non-CodePlex side of the house like Bob, Yag, and Dave (internally, we refer to the non-CodePlex projects as "Athens"), you are probably aware that we are trying to take on the social computing technologies. Traditionally, we've been a meat & potatoes sort of group, building on-line forums, chats, and working with our partners at Telligent on blogs. About a year ago, I took this role and met with each of my new direct reports. When I met with Vikas (my Test Lead) for the first time as his manager, he spent most of our meeting on a rant about how we were continually behind the curve in what we were building (if you know Vikas, you'll realize his rants aren't quite like mine as he is far more reserved). He felt we were playing it safe, taking on projects that added value but weren't game-changers. This was just before my paternity leave, so I spent a month thinking about his words and I didn't have an answer. I wanted to say "but we're doing important stuff" (which we were), but Vikas is a smart guy and he was right. While neither he nor I would say that building something like Forums isn't extremely important to Microsoft, I think of the words of Woody Allen in Annie Hall in describing relationships as being similar to sharks: "It has to constantly move forward or it dies." I think that goes for software organizations as well. I felt this team had to move forward or it would die. Execs would question our usefulness and future investment. Our technical talent would get bored. The product management folks would be reduced to taking feature requests from product groups like a waiter takes orders from a customer (that was already happening). As the new leader of the team, I had an opportunity to make a change. While I would do everything possible to honor the commitments to the existing sites (including currently ratcheting up an entire team in China dedicated to just solidifying and updating the current Forums), I wanted to do something that would truly change the way people interacted with Microsoft.com and with one another.

A month later, I met Bob Rebholz at a time he was looking for a job. He asked for an informational interview about positions we had. For the first half hour, (to borrow a Scott Densmore phrase) I thought he was "trying to sell crazy". The second half hour, I knew he was trying to sell crazy. The third half-hour, I had my money on the table. He spun tales of tagging, social bookmarking, reward systems, and other mechanisms that connected people to other people. Even at Microsoft, we were doing some amazing stuff in the XBox division around gamer tags and this idea of building relationships on-line and he was asking why we were missing the boat. Where Vikas knew we were missing a vision, Bob offered his own as reflection of what was going around in the world around us and this notion of "Web 2.0". This was around the same time Josh and I were discussing whether Q&A Forums are truly community if there was no "sticky" connection with the people involved. I wanted to make that sticky connection that brings people back. Bob won me over by showing me the success that was already being achieved through these concepts with Flickr, del.icio.us, and several other sites. He told me how he connected to so many different people through these worlds--people to whom he remained connected. He also told me how his teenage son was using the new technologies (if you want a harbinger of many things to come in technology, watch the kids). Before I listened to Bob's take, I avoided a lot of the Web 2.0 stuff. With the exception of this blog, I didn't think I needed it. But Bob convinced my to try and now I can't live without many of those sites. But even more exciting was that this stuff was what I was tasked to do--I could work on this on behalf of Microsoft! This was community. This was risky. This was a game changer. If there's one thing I've learned from Microsoft's history, you have to be willing to "bet the company". To quote David Treadwell (former .NET VP who now works for Ray Ozzie) from one of our CodePlex executive reviews in the early stages of development, "if you are going to play, play to win".

But (yes, you knew there was a "but") not everyone embraces a big risky bet. For those who read business books, you may be familiar with "Innovator's Dilemma", the book from Harvard professor Clayton Christensen that built this notion of disruptive technologies, which upset the balance of the marketplace by rendering the incumbent technology obsolete over the long-haul. What makes disruptive technologies so potentially disruptive is that the producer of the incumbent technology has an obligation to its current batch of customers and, therefore, cannot fully invest in the new technology for fear of jeopardizing its exisitng revenue. Classic example include what digital cameras did to the photography business and what CD-ROMs did to traditional encyclopedia businesses. Whether you were Kodak or Encyclopedia Britannica, your core competency was in jeopardy. Kodak was all about the world's great film, while Britannica made a reputation on door-to-door salesman and huge collections of books that sat in your den. Suddenly, these new technologies come along with the express purpose of eliminating the need for those core competencies. What do you do? Do you jump on the bandwagon, risking your current customers for something that may or may not pan out? Do you stick with that you know and trust that the hype will blow over? There's never an easy answer. But I do know this much: if you don't take new trends seriously, one of them will obsolete you very quickly. I believe that Christensen was focusing on old companies vs. startups, so he didn't really address the concept of intrapreneurship (entrepreneurship wihthin a company). In other words, what happens when two groups within the same company have conflicting objectives as one side supports the general business while another side goes after the potential opportunity? Christensen implies that it can't be done, but companies like Microsoft do it to stay alive. Ray Ozzie is spending his days and nights making sure that "services in a cloud" trend is not lost on Microsoft, even as we are heavily invested in packaged software for tens of billions of dollars. It's not an easy thing to deal with, especially those who consider software-as-a-service as a fad. I spent months fighting conventional wisdom while we built CodePlex, where we seemed to be endorsing open source--which many saw as counter-culture to the Microsoft way of life. In fact, my real contribution to that project was managing the FUD (fear, uncertainty, doubt).

So, when it is suggested to me that our work with social computing ideas will do "nothing to increase the satisfaction of developers", I am not sure whether to get frustrated, upset, or laugh. Many of them are the same ones who told me not to build CodePlex. Now, in the words of Yogi Berra, it's "deja-vu all over gain" as I need to convince people that change is among us and we are doing the right thing and ask for patience. In my opinion, we were vindicated with CodePlex. Will that happen with Athens or are we going after something that is going to fall flat on its face? Are we building something that will add no value to Microsoft? I believe it will succeed, but we'll only know years from now when history will tell the story. As long as our goal is to change the game, I'm in.

"But the bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it."

- Thucydides

'What The Heck Is He Doing Here?'

SandyK — Tue, 24 Oct 2006 22:29:00 GMT

For the last few weeks, I've been spending one day a week sitting in the shared workspace that several members of the Microsoft.com Commuinities team uses. We have about nine people sharing one large office in Building 6 that was once home to Bill Gates and then Steve Ballmer. "So what?", you may say. Well, I'm a manager (and in fact the manager of their managers) and therefore don't do any of the "real" work. In fact, I have my nice solo office where I can play my music, have private phone calls, and handle drop-ins from anyone on the team. Why on earth would I skip that for an admittedly cramped office that is bursting at the seams with little to no privacy? That easy: Spying. OK seriously, when someone e-mailed and asked me why I do it, I itemized some reasons and after I wrote it, I thought it would make a good blog post. It connects a little be with trying to be the best manager I can be for a team trying to do agile development and some other ideas about what I think effective leadership and management is about.

I am doing it for several reasons:

Empathy: I know it’s cramped in there and I am trying to empathize a little bit. I've grown to be a big believer of the shared workspace as a means of fostering (forcing?) communication between team members. Microsoft is an e-mail culture and e-mail leaves no room for nuance of diction or truly constructive dialog. But Microsoft facilities also weren't designed to support the shared workspaces and we've had to improvise. As a result, some of the conditions are tight. As I explained to the teams, I have a solo office because I need it for meetings, but I don’t like the “exec washroom” exclusivity it fosters, so this is my way of at least showing that I get it.
Communication: In the same manner that the shared workspace is about opening the lines of communication between teammates, the days I sit in the office are partly meant as an open forum for anyone to ask me questions at any time. I've tried to do lunches with each of the teams, but that comes off as a more contrived environment. Meanwhile, with the shared workspaces, it’s harder to do the “management walk-by” when people are sharing offices, so this opens the lines of communication. I'm just there working away, so if you have anything to say, go for it. I think I've gotten some pretty thoughtful questions and feedback as a result, including the fairest question of all: what do I do on a typical day? (Answer: there is no typical day)
First-Hand Knowledge: Get a little more in touch with the development teams. It's my effort to “trust but verify” the info from the leads that report to me. I also like the idea of being closer to the trenches whenever possible. I was reading the Wired article on Ray Ozzie and how he likes to sit with developers and practically work with them because (a) he understands the code and related issues better and (b) he draws a lot out of the conversations that are happening at the time. I don't know if I'll be pair programming with any of these guys any time soon, but I do think being "on the ground" helps my appreciation of the situation and associated challenges.
Feedback: Opportunity for the teams to show me their work, if they so choose. We are having monthly demo days , but if they want interim feedback, here I am. Also, to the point about Ray Ozzie, I also like hearing the conversations and issues that arise in the daily work that goes on. It's hard to give feedback on the spot (which is essentially what I ask people to do in one on ones or at the team lunches), but in the course of the day, many things will pop up.
Fear: Scare the living bejeesus out of them to keep working and not slack (that’s just a fringe benefit) ;-). OK, that's not true at all and that's part of why I picked Fridays--I want to pick a day that is a little more mellow, perhaps. Hopefully, the moods are a little better, people are looking forward to the weekend, and they can be a little more informal.

I don't think I would have done this nine months ago. I think there is a comfort zone that I think I feel with most of the team that allows me to do this. I’d do it for some of the other Microsoft.com Communities teams (there are two other teams as well as the CodePlex team), but those teams are either smaller where my presence might be a little more imposing or, in the case of CodePlex, they'd intimidate me :). In all seriousness, I do worry about the work equivalent of Heisenberg's Uncertainty Principle (the position of an object can't be determined because it is affected merely by being observed). I don't intend to scare them and hope that isn't the end result. I only do it one day a week because it's all my schedule really allows and I don't want it to reach a point where it does feel like Big Brother.

{Dave Matthews - Some Devil}

Management Accountabilty in a Scrum World

SandyK — Tue, 30 May 2006 21:40:00 GMT

Last summer, I was having a conversation with a friend who worked in Microsoft Research. I knew him from outside of work and we rarely talked shop, but in this specific instance, I was telling him about my projects. The biggest project on my plate was CodePlex. After bragging about the featureset, I began describing the way we were building the software using the agile methodologies, from the spike we did at the project inception to the weekly iterations and TDD. I was telling him about how we were even trying to get a shared workspace to put the entire team in one room (we did get it and, while it’s not as cool as my old team’s workspace, it is the office once inhabited by Bill Gates and then Steve Ballmer—so that’s pretty cool)…

My friend’s response took me a bit by surprise. He was more impressed with the development approach than the product and he went out of his way to not only praise the team, but also praise me as the manager. He pointed out few managers had the patience and trust to support agile development at Microsoft as there’s a leap of faith that is required and trust in the team. He believed managers couldn’t handle the ambiguity of the schedules and deliverables (though I believe that is changing at Microsoft). After all, with waterfall software development, everything is lined up and the dates are in stone—when you say it is going to be “Code Complete”, it will be complete. That’s a mirage, of course as software projects rarely hit dates, but managers still manage to get some level of satisfaction from deluding themselves. Personally, I’ve always felt that you can’t effectively run a business on a twelve-month ship cycles and assume no changes. Waiting until month eight to determine there’s a slip or key features will get dropped is borderline suicide. Either the product will come up short of expectations or the date will slip and surprise upper management. It also guarantees the infamous death march. The ability to continually course-correct is something that has a sister-theory in business called “Discovery-Driven Planning” and I see it in the NFL every Sunday in the Fall. But agile is not perfect and isn’t the cure-all for every software project. What happens when results are less than perfect?

Recently, Doug Seven from my team posted a blog entry entitled “Accountability in a Scrum World”. In the past several months, Doug has really come to embrace many of the agile principles. Well, with one of our projects, a team that is very new to agile development had struggled with the first two iterations. Doug was obviously frustrated with the progress and was trying the get to the root of the problem. In this specific case, I think there were many things working against them that make any sort of assessment unfair. Plus, to judge after two iterations in any case is WAY premature. I think it’s easy to fall into an expectation of everything working in textbook fashion from day one. Guess again—nothing in life works that way. While I myself am inherently impatient, this is one case where I refuse to be so. In fact, I gave the team a short-tem goal I felt was very achievable in a fair timeframe. I wasn't looking to stretch the team on a deliverable. In fact, my manager and I locked horns about it as he thought I was sandbagging. In a way, I was. Why? Because I wanted the team to have enough room to take risks. If you are under time pressure, you will revert to your old approaches. When adopting agile development, teams need to be allowed to struggle without fear of reprisal. Changing the way you do your craft is scary and that’s what we’re asking from the team. As a manager, I need to be willing to make the short-term investment for the long-term prosperity. Again, it's a matter of trust.

The unintended consequence of Doug’s post was to scare the team into thinking they were under the gun, which draws them back into the world where they fear failure. That spins them into a world of the blame game, whether it’s teammates, the process, management, and other things. And let’s face it—all those are likely guilty of something, right? I don’t want people on that team thinking about reviews or their bonuses or anything like that and their need to defend that (yes, that is naïve, but I want to at least minimize focus)—I want them focused on the success of the team. To the sports analogy, the athlete should be thinking about winning a championship first and then trust that if he contributed sufficiently to the cause, he will be rewarded (yes, another sports analogy—I can’t help it).

But, to Doug’s question, what of accountability? Not in the case of this team, but with all teams, successful and not. With the infamous Microsoft performance curve no longer in existence, we can now operate in Lake Woebegon, where all the children are above average (well, not quite…). I believe the only way agile works is when everyone feels accountable for everyone else. That’s the purpose of the daily stand-up—people sharing their progress and their obstacles, in some cases looking for help. If one person fails, everyone fails. Communication is vital, everyone on the team should be looking to assist, not blame, and the accountability must hang with the team. At the end of the project, you can certainly do the retrospective and recognize who stepped up for whom. I’d rather reward the person that chips in to help a teammate get past a tough issue than someone who writes the random killer feature. I'm not talking about the hero dev thing (which can be a different problem), but rather taking care of the little things and removing obstacles to keep the cadence. In fact, I’ve been on projects where one person failed miserably, but the team was successful because the rest of the team stepped up. Once the project shipped, the rest of the team was rewarded nicely and the person whose contribution did not measure up was not with the team for long. That said, we gave him the full v1 release to prove his worth before casting judgment on him. But when you start playing the individual accountability game from the start, then it’s every man for himself. Agile will fail in that mindset. My personal management philosophy is to keep an eye on any unique events that need immediate attention, but I try to reserve judgment on people until the project is out the door. Trust the team and give them the ability to self-correct. Once they ship, it is clearer to assess why the project was able to ship and what could’ve been better.

So will the team that struggled with the first two sprints succeed? My confidence is very high. There’s too much talent there for it not to. In fact, the third iteration has already gone MUCH better by all accounts. But just as I won’t judge the 2006 Orioles baseball season until October (though I will keep an eye on the standings), I won’t judge this team until we’re much further along in the project. They know what they’re accountable for as a team and that’s all I am keeping an eye on at this point.

{Foo Fighters – In Your Honor}

Revenge of the Marketing Nerds

SandyK — Wed, 26 Oct 2005 18:21:00 GMT

Recently, Microsoft went through a major reorganization that really changes the primary leadership of this company. Three primary groups were created to divide the business into broader areas of focus. While many are speculating on why Microsoft did this, I am actually very interested in looking at who they did it with and the ramifications. As someone pointed out to me, all three new presidents (Jim Allchin will be stepping down in a year, so I am not counting him) are essentially marketing guys. Jeff Raikes was Microsoft's first-ever product manager and spent a great deal of time running the sales organization. Kevin Johnson has an undergrad degree in business administration and was the most recent head of sales & marketing. And Robbie Bach is a Stanford MBA that has marketed products throughout Microsoft. All three will report to Steve Ballmer, a near-Stanford MBA who also led the sales & marketing organization at one point. For a company that prides itself on its technical prowess, that's a whole lot of marketing prowess at the top.

The funny part is there are times when I feel like my b-school background was almost a liability at Microsoft. Don't get me wrong--it was definitely a useful education and I draw on it frequently. However, I think I didn't really get the respect until I was able to speak intelligently to the technology. That's the kind of culture Microsoft is--it's all about the technology. So the fact that arguably the four highest-ranking officials at Microsoft (not counting Bill Gates) are marketing guys is fascinating, especially on the heels of Intel naming their first-ever CEO without an engineering backgroun in Paul Otellini. Don't forget MBA and ex-management consultant Kevin Rollins taking over for Michael Dell. The next generation of the dominant PC companies is being turned over the (gasp!) marketing guys.

So what does that say about the tech industry? To paraphrase the best answer I've heard about turning Microsoft over to the marketers, it's less about technical knowledge and more about leadership. The fact is: Bill Gates didn't write a line of code in the 90s, but he is hugely responsible for the success of Microsoft due to his business savvy. While his ability to grasp technical details is incredibly important, it's his ability to translate that into a cohesive set of marching orders to enabled Microsoft to navigate through the highs and lows that were the 80s and 90s. Strong companies need strong leadership, regardless of who brings it. Bill Gates brought it and I think Steve Ballmer brings it.

Still, the question is "why marketing guys"? After all, aren't there technical leaders? Probably, but I think this is a sign of understanding that these companies have less of a technical responsibility and more of a customer responsibility. When we focus on the technology, we do a disservice to the customer. The technical guy goes "wow, this is really cool". The marketing guy goes "wow, soccer moms are gonna love this and therefore spend a lot of $$ on this". Take Steve Jobs--most hail him as a technical visionary, but he is the world's greatest marketing guy (no, that's not an insult). Wozniak was the technical force behind the early days of Apple--Jobs just put it in the perfect context. By the time Jobs returned, he helped bring the iMac to the market (bubble gum computers are hardly technical innovations) and eventually products like the iPod (plenty of MP3 players, but the iPod hit the mark). These are products that triggered a reaction from regular people. I admit that I envy that thinking and hope Microsoft does more of that. Cool doesn't make $$--changing people's lives does. I see signs, but the next 12 months will be the best indication. Good luck to Bach, Raikes, and Johnson. The world is watching...

{Coldplay - X&Y}