Saturday, September 20, 2008

Bill Gates, the technical leader

Everybody knows Bill Gates, the business leader. He visualized the impact of Personal Computers and systematically monetized it to create monopolies in OS and applications markets. Bill Gates also played the role of a technical leader with passion. Here I have tried to create an image of Bill, the technical leader based on Cusumano’s classic book Microsoft Secrets and Bill’s interview at National Museum of American History. Unless stated all the statements below are from Bill.

Seeing “The most technical” as competitive edge: "We were more comprehensive. We weren't the largest. There was a time that MicroPro with WordStar was bigger. There was a time when Visicorp was bigger. There was a time when Lotus, with the early years of 1-2-3s incredible success, was bigger than we were. But we were always the most technical. Whenever anybody else in the software industry wanted to know where we thought things were going, they'd come and talk to us. Because our vision, we shared; we didn't view that as some competitive edge."

Bill’s product understanding: Dave Maritz, former test manager, Windows/MSDOS says, “He is a maniac. Bill knows more about the product than any of us. And you go into the meetings and you come out just sweating because, if there is any flaw, he will land on it immediately and pick it to bits. He is just unbelievable.” Bill himself says, “The products that comprise 80% of our revenues, I choose to understand very very deeply”.

Bill’s strategic memo: Bill used to write strategic memos four to five times a year. One such memo was on “Some of the big technical challenges we face and who is going to own particular solutions and what solutions are the right ones from the strategic point of view”

Bill on code review: If a project really appears to be broken, then you want an independent review of the code. Very early in the company I’d say, “Hey, give me the source code. I’ll take it home.” I can’t do that now. So I take somebody a D14 or D15 (top technical ranks) and say, “Go dig into this thing and let me know”.

Bill on code sharing: I believe in code sharing across the groups. I’ve imposed on them the necessity to get this thing from this group and that thing from that group, and those groups don’t work for them. If they want to point out some massive bug, it’s important to bring that out in the discussion.

On letting go: Well, at first, I wouldn’t let anybody write any code. I went in and took every statement that anybody else had written in BASIC and rewrote it myself, just because I didn’t like the way they coded. But then we had products like FORTRAN and COBOL, where all I did was make sure that we were designing to the right spec and review the basic algorithms… I have not delegated the general idea of products to develop (in early 90s).

Sunday, September 14, 2008

Overcoming idea resistance#2: Apollo13 technique

How do you push your idea in a highly process oriented culture? Well, a lesson from Apollo13 story says, you don’t push it, you just shove it in! All you need a deep conviction as to what is “the right thing to do”.

Most of us are familiar with the story of Apollo13 through Tom Hank starrer Oscar winning movie with the same title. Apollo13 was brought back to earth in a miraculous manner after it was crippled due an explosion right after its launch on April 11, 1970. The explosion damaged its main engine (Service module). The crew used back-up engine from Lunar module as a “lifeboat” in space. What few of us know is how the “lifesaving” backup engine capability was built. Let’s look at the sequence of events from the eyes of our hero Ken Cox who was the Technical Manager for the Control System program (story from 4th Generation R&D: Managing knowledge, technology & innovation). The development work involved people from Rockwell, Grumman and MIT Instrumentation Lab.

Late 1967 (30 months before Apollo 13 launch): Ken discusses the scenario with MIT folks “We really ought to have a contingency mode for coming back from the moon if something happened and you could not fire the big command service module engine”

· Ken talks to his counterparts in the propulsion engineering design group, and they said, "Oh, no, we would never have an explosion like that. No, no, no. That's not a credible scenario."

· When Ken took it to Apollo Program Office (like any other Program Office) it asked, “What is the problem, and what is the probability?” Ken didn’t have, in his own words, foggiest idea what the probability was. So the Program Office said, “Well, but you haven’t proved yet that this is really needed.”

· Ken brings the issue with Apollo Software Control Board which was run by Chris Craft. Chris said, "Ken, I think that you've done good work here, but you haven't proven that you need it, and therefore your request to put this in the basic capability of the Apollo program is disapproved."

· Ken is crushed. He said to himself, “I don't give a damn whether I can prove it or not! It's the right thing to do!”

· As Ken is walking out of the door, Chris motions him to the other side of the room. He looked me right in the eye, and there was a twinkle in his eye, and he said "Put that mother in as soon as you can”

· In the next Software Control Board meeting, Ken says, “We have done this action, we have put it in the main line configuration control and if you turn this proposal down at this point, it will impact the program because you will have to take it out." And Chris had a twinkle in his eye, and he just said, "Well, if that's the case, I think we just ought to keep it in and accept the design.”

Which one do you think is more difficult to find? Conviction as deep as Ken's or people like Chris with twinkle in their eyes?

Tuesday, September 9, 2008

Overcoming idea resistance: Judo technique

Say you have an idea: it may be a new tool or a new feature you thought of or a new product altogether. And you want to really give your best shot at getting it accepted. What do you do? Well, you may say, I will start with building a prototype or Proof of Concept (PoC). So you spend anywhere from a couple of days to a month working extra in developing this PoC. What next? You may say, I will show it to my manager or product manager or someone else in my business unit I have a good rapport with. This approach-1 looks like this:







Is there anything wrong with approach-1? Nothing wrong, except that the idea may not have enough weight of its own yet. And chances are high it may not get appropriate priority in the list of things the business leaders want to focus on today. You may say, well, is there any other approach? And this where John Seely Brown, ex-Director of Xerox PARC shows us a different approach he calls “Operational Judo”.

This is how John describes his approach in article How does your knowledge flow? First, we got customers turned on to the idea by showing it secretly to them. That helped us make improvements by learning from customers. Once we got customers behind the idea, we unleashed them on the other parts of the company. We did that because we knew an idea from a customer would have greater credibility than one that came directly from us.

John’s Judo Approach looks like this:





It is easy to see which approach has higher chances of overcoming the resistance to your idea.

Thursday, September 4, 2008

Story of how Google’s AdSense almost got killed

Adsense: Google’s AdSense technology has enabled arguably the most successful business model innovation of this decade (at least so far). Google’s VP of search products and user experience, Marissa Mayer narrates the story of AdSense innovation in a podcast at iinnovate.com. What makes this story interesting is to see that even an AdSense kind of innovation underwent near death experience. Let’s look at the events briefly below.

Sequence of events:
1. Paul Buchheit, tech lead of gmail project and Marissa, that time the Product manager for gmail, shared an office and got into discussing how they will make money from gmail. Marissa says, “We will give small mailboxes for free and upsale on the large mailboxes.” This was the prevalent business model that time. To which Paul says, “I am not so sure. May be we should put ads there.” Marissa immediately reacts saying, “Paul, Paul, Paul. Ads are not going to work. We won’t be able to find relevant ads and then there will be privacy concerns”.

2. 3am – Marissa is about to leave the office. She leans back from the door and says, “Paul, we agreed we are not exploring the ad thing, right?” Paul responds, “Yeah”.

3. 7am – Paul leaves his office after finishing a throwaway prototype implementation of adSense (see Paul’s interview)

4. 9am – Marissa is back to office and logs into gmail and sees ads everywhere on the screen. First reaction is “Oh my gosh! What has he done?” She feels like calling him immediately to take this off. However, she resists it because she feels Paul should sleep for at least a couple of more hours before she disturbs him.

5. Between 9am & 10am – Marissa gets 2 emails. One from a friend about going hiking. And an ad pops up for hiking shoes. Then another mail comes saying Al Gore is visiting Stanford. And an comes up showing Al Gore’s books.

6. 10am – Marissa is beginning to appreciate this ad thing.

7. 11am – Sergei comes in and he likes it too.

Rest is history.

My takeaway: So what is the moral of the story? I can think of 2 possibilities from which we need to pick only one (I guess a story should have only one moral, right?)

1. Don’t react to others’ ideas negatively. Be supportive. (Don’t be like Marissa)
2. Listen to others, and do what you feel to be the right thing, anyway. (Be like Paul).

I would any day go with the latter statement (#2) because I don’t have control over others reactions. And, more importantly, Marissa’s reaction is the most natural reaction to radical ideas like AdSense. I would have reacted the same way, if I were Marissa. And hence, “Being like Paul” helps.

Wednesday, September 3, 2008

Homebrew Computer Club: A role model for communities of practice

Homebrew Computer Club, a role model: When Apple co-founder Steve Wozniak writes “Without computer clubs there would probably be no Apple computers” he is actually referring to Homebrew Computer Club. The Homebrew Computer Club was an early computer hobbyist club in Silicon Valley, which met from March 1975 to roughly 1977. From the ranks of this club came the founders of many microcomputer companies, including Bob Marsh, George Morrow, Adam Osborne, Lee Felsenstein, and Apple founders Steve Jobs and Steve Wozniak.

How did Homebrew Computer Club operate? Homebrew members were hobbyists, most of them had an electronic engineering or programming background. They came to the meetings to talk about the Altair 8800 and other technical topics and to exchange schematics and programming tips. According to Steve, each session began with a "mapping period," when people would get up one by one and speak about some item of interest, a rumor, and have a discussion. Somebody would say, "I've got a new part," or somebody else would say he had some new data or ask if anybody had a certain kind of teletype. This would be followed by “Random Access Period” during which members would wander outside and find people trading devices or information and helping each other. Steve would bring Apple I and II to the club and demo the progress as the designs evolved. In fact, Apple’s first major order came from a retail shopkeeper who was a member of the club as well.

What made Homebrew Computer Club special? Well, I have been part of various Communities of practice myself. And I have not seen anything like Homebrew. I find Homebrew special because it created an amazing innovation platform from which a whole new (PC) industry was born. Here are a few characteristics of Homebrew that I find interesting:
  • Homebrew members were all passionate about one thing: making home computer (which was an unmet customer need at that point of time).
  • Many of them were expert hackers and playing with circuits by hand themselves (Steve would go visit some of them and fix their circuit problems)
  • Members also included component traders and people who ran businesses (and some who closed them) and it gives an interesting business perspective to this geeky game (Steve writes, occasionally somebody would show up and say “"Is there anyone here from Intel? No? Well, I've got some Intel chips we want to raffle off”)
My takeaway: (a) Having a common binding vision which is linked with unmet customer need (b) having expert and passionate practitioners as members and; (c) having members with business perspective (like component traders) looks to me an ideal combination of an innovation platform.