Lessons Learned from the Browser Wars

to today’s TechTalk. It’s my pleasure to introduce
Scott Berkun who comes to us as a project manager from– well, actually he is a lecturer
and author and a trainer of project management. And he learned a lot
about project management at his tenure– and that actually
was 10 years– at Microsoft, where he was
a project manager there, primarily working on the
Internet Explorer. And so he’s here today to talk
about his experience. We also have another session
this afternoon from 1:00 to 2:00 which is geared toward
project leads, and is more a Q&A session. And if anyone would like to
join for lunch today with Scott, please stay after. Thank you. SCOTT BERKUN: OK. Microphone good? Microphone check. People in the back? Waves, still awake? OK. I’m not a morning person. This is still morning
time for me. So you’ll find that my pace
gets better as the morning passes into afternoon. If you guys are not morning
people, thank you so much for showing up. I’ll try to keep you awake until
we make it to lunch. What I’m going to talk to you
about today is actually a very difficult talk for me to do. When I talked to Carolyn about
coming here and speaking here, I had published a book
that came out. And I’d talked to everyone I
knew about where I could go, maybe talk about some of the
things from the book. Carolyn and I talked, and
we tried to come up with something more interesting than
just telling you about, well, page 27 tells you– You know, I don’t want to give
you a verbatim of the book. So we said, well, let’s talk
about stuff from the browser. Hey, yeah, I spent a lot of
time working on that. There’s good stuff to learn. Maybe you can learn
from my suffering. So that’s where this
talk came from. The problem is that the list I
came up with for lessons that I learned was several
pages long. And when I showed it to a friend
he said, none of this is interesting to me. It’s all interesting to me. My lessons, what
did Scot learn? So I had to spend a lot of time
refining this to be not just lessons that I learned, but
the lessons that I learned that might be interesting to
other people, especially to people at Google, and people who
might not be old enough to remember when the browser wars,
the first browser wars, took place. So I’m not going to talk too
much about the book. I’m going to talk about it a
little bit at the beginning. I’ll pass the book around. You can look at it to prevent
you from falling asleep while I’m talking. But just to give you the
background on me, beyond what Carolyn said. I left Microsoft in 2003. And I left to write books. I decided that I want to spend
time writing books. So it took me a while to figure
out how to do that. I didn’t know how to put
sentences together. I’d been spending so much
time as a manager. Got my book together. While I was writing the book,
I started working as a consultant to bring in money
while I was writing. And my plan, right now– this my
first book– is to promote the book, see how
well it does. Try to keep doing consulting and
teaching, so I can write the next book. And I can come and talk to
people like you again. And have a good time and make
fun of Microsoft and all those good things. So the book captures, or tried
to capture, everything I thought I learned in being a
team leader at Microsoft. And I tried to distill
it down into– you don’t have to be a
development lead, you don’t have to have the word manager in
your title to get value out of this stuff. It’s all about, how do you
make your decisions? If you’re working with other
people who are smart, how do you effectively communicate
with them? How do you build good
relationships? What do you do when
things go wrong? I tried to break it down into
the 15 or so things that really make the difference
between being successful and not. Today, in the stuff about the
browser wars and what I learned then, there’s a couple
things that are related to what’s in the book. How to figure out what to do. What to do with the ideas. Writing specifications. How not to annoy people,
which is actually a chapter in the book. I’m very proud that they
didn’t cut that out. Mid-game strategy, and,
of course, what to do when things go wrong. So my agenda for today is, an
important announcement to make, I’m going to talk about a
brief history, just refresh your memory on the first
of the browser wars, the history part. I’m going to talk about process,
smart people, and organizations, writing
specifications, about managing innovation, and then about
business and customer challenges. So my important announcement
for you, this is extra important if you like beer. As part of my no frills,
self-funded book tour, the social event for my tour
is tonight at 7 o’clock at this brewery. So if you like beer, if you like
project management, if you find something I said today
entertaining, if you want to come to make fun of the
ex-Microsoft guy, you’re all welcome to come. I don’t know how many
will show up. I don’t know how much
money I’ll have left to put towards beer. But as much as I have I’ll
put towards beer. And you’ll get a free
beer from me. And if I have any books left,
I’ll give them away. So you’re welcome to come. That was the important
announcement. Here is the 30 second, top speed
summary of the first part of the browser wars, just
to get some context. 1993, bunch of people made this
thing called Mosaic, did it as a public works project. Bunch of people left, created
a company called Navigator. Actually tried to market the
product as a corporate, capitalistic endeavor. Microsoft created Internet
Explorer which was based on the code that they purchased
from the people that made Mosaic, which shipped as
part of the Plus pack. This is where I came in a little
bit, I worked on Plus pack, I worked on IE v1.0. It wasn’t even part
of Windows. It was this thing you had to pay
extra for, that you got on a separate CD. All of a sudden, boom,
everything– Navigator took off, millions
of downloads. And now all the browser
wars were on. Navigator 3.0 and IE 3.0,
that was 1996 and 1997. That was the first wave. Internet Explorer 3.0 was
actually well received. And all of a sudden everyone
said, wow, Microsoft is in the game. IE 4.0, which a lot of the bad
horror stories I’m going to share with you, come
from this. Has anyone here worked
on IE 4.0? I know there’s a bunch of
Microsoft people here. Any IE 4.0 veterans? Good, I can tell
you the truth. OK, excellent. OK. Then, towards the end, Netscape
was acquired by AOL. Some people say that
was the end. Some people say that it
was over before then. But when that happened, that
was right before IE 5.0 was released, which did well, was
popular, was well received. And that concludes the first
part of the browser wars, in a very encapsulated fashion. If you really want to
get a full history– I’m not going to give you the
documentary version, the Roger Moore version of what
happened but– there are books about this. One book that I can recommend
to you, which is more Microsoft bias, is How
the Web was Won. It gives you a chronology
of all of the stuff that happened, very business
focused. The other one is Competing on
Internet Time, Lessons From Netscape and it’s Battle with
Microsoft, which is more focused on Netscape. I read all these books in
preparing for this talk. And I have to tell you, given
that you guys work at a company that is in the center of
the industry, books will be written about what
you’re doing now. And, before you read them, a
couple of years from now, before you read them,
have a few beers. Because what they say,
you’re like, what? Like they’re talking about
things you did in a different context. Like, OK, maybe that’s what they
said happened, but that’s not what I remember. So just preparing
you for that. Now let’s get on with
the actual talk. Every team, every project
is different. Now when it comes to thinking
about how software development is done, or how project
management should be done, what kind of coding technique
you should use many people develop opinions based
on their experiences. They come up with philosophies
about how things should be done, you should
always do this. You should always implement
things this way. You should always write this
kind of specification. And, the thing that I learned,
through Internet Explores, but also other places, was that kind
of militant, religious attitude about how work is
done is not productive. Because every time you start a
new project, every time you start work working with
different people the dimensions are different. The problems you are
likely to have are going to be different. The strengths of your
organization, your little team, are going to
be different. And what you’re trying
to achieve is going to be different. So when you walk into a door and
say, well you know we’re starting a project again. So that means we’re going to do
it the same way we did it the last time. You’ve got this preconceived
model that you are forcing onto a new universe that isn’t
necessarily going to benefit from the previous model. The universe is changing
all the time. And something is wrong if you
walk into every new day bringing with you the same
things that you feel like you learned in the past, that you
are trying to make happen in the future. By the same token, if your
opinions change all the time, you’re not paying attention
either. So there’s this joke
that we had. There was someone that I worked
with on the Internet Explorer team, I won’t
mention his name. But he was a project manager,
program manager like myself. And his opinion would always
match whoever spoke last, whoever it was. So if you come in and say, we
should do A. A. And then someone would say, I think we
should do B. We should do B. Let’s do B. We called
him the weathervane. We called him WV, because any
time that something new happened, he would say we should
go with this new thing. So, as an example, this is one
way to look at my recollection of the Internet Explorer
versions that I worked on. And, even though this started
with a small team, the IE 1.0 team had about 15
people on it. And I was actually working
on the IE 1.0 team as a usability engineer. I was not a project
manager yet. It was a very small team. We were off in a corner
of the company. No one cared what we did. It was a fledgling little
effort, very organic. We didn’t really write specs,
we did whatever we wanted. IE 2.0 was the same way, except
now there was starting to be attention placed upon
the team and what we did. because it seemed to
matter more to the rest of the company. So we were still small, still
organic, no real structure or disciplined engineering
process. Bunch of people in the hallway
making stuff, right? But now we’re strategic. Then all of a sudden the
team got bigger. Still organic, still strategic,
but now the size of the team is larger. So I’m not going to walk you
through all these things, because you can read
it on the slide. But in each one of these
projects, the needs for how much process we needed, the
need for what kind of specifications we should
write, the needs of the engineering tools we used were
all a little bit different. And I don’t think that we really
paid attention to that. All the people that had worked
on IE 1.0 and liked working in that way, by the time
they got to IE 4.0– which became a really
large team. The IE 4.0 team probably had
about 250 people on it, 300 people maybe. I don’t really know, somewhere
in that ballpark. So going from 15 to 30 in about
three years, that kind of growth, all these people were
still thinking, I’m going to work the way I
worked before. In some cases that would work. But if they were working on
things that affected 100 other people in the group, there
were problems. So one lesson, the needs
of a team or project are always changing. Smart managers and leaders are
paying attention to the moment, today, being here now;
what does this team need from me as a manager, from me as a
leader, in terms of tools and process and structure, writing
specs and build processes and all that stuff; and is thinking
about today, and is not thinking about how they
want it to be, or how it should have been, or how
it could have been. The word “process” comes up a
lot, and most people don’t like that word. They think of assembly lines,
which is what the picture is in the background. They think of factory, you’re
going to make a process for doing something. You’re going to take all
the fun out of it. You’re going to bleed it dry. And you’re going to make
my role insignificant. Oops. I don’t think that process is,
necessarily, a bad thing. It all depends how you define
“process.” And I think that the way people tend to define
“process,” thinking of like college culture, computer
science department culture, process is this thing that
manager people, who don’t know anything about technology,
impose on everyone else. That’s what process means. That what they think it means. I think it means
something else. I think it’s any series
of tasks that you do to make something. That’s what a process is. So if you’re hacking
away, you’re up all night, having fun. And you make some thing that
you think is cool, that you show your friend. That’s a process. If you were to sit down and make
a blueprint, and spend six months planning something
before you’re wrote a line of code, that’s a process too. Different kinds of processes,
depending on what you’re trying to do, a different
process might be appropriate. When you’re thinking about,
is our process good? Is my team using
a good process? The way you know is thinking
about it from one step back. Not the method, not are we using
extreme programming, are we using the waterfall
model, are we using this kind of code? You say, OK, is this
process going to help us to be effective? How effective are we now? How effective would
we like to be? How effective do people
feel they are? Is this process making us
more or less effective? Can we put something in place
so we make better decisions? Like the code review
idea, minimizing the chance of mistakes. So some way to make sure a
stupid mistake is avoided, good process will help
make that happen. You think of like
warning signs. You think of warning labels
you get on things. You think of a stop sign at the
corner of an intersection. That’s a thing that is put
there to help you in the process of driving, to
help prevent you from making a mistake. Makes sense. Now sometimes– this is where people start
to get the rub– a process may ask individuals to
pay a local price in their daily activity, to benefit
the larger group, coding standards, coding practices
that you have to use, or following a certain template
when you write a specification. You’re paying a local tax,
I don’t really want to follow this form. But because I’m doing it, and
everyone else is doing it, the whole group benefits. This is where it gets
complicated. A good example in the world is
the highway system, which, by my definition, this
is a process. This is a process for driving. It’s a set of rules that
prevent you from doing certain things. You can’t drive wherever
you want, right? But by following the rules you
benefit from being able to go relatively quickly. You’re guaranteed that,
as you’re driving, the guy next to you– well most of the time– will
stay in his lane, right? That allows you to go at
75 miles per hour. Because everyone is using the
same process there’s money that can be spent to make the
roads safe and reliable. And there could be lights
on the road. And there are these barriers
to prevent you from falling off a cliff. This is all good, right? I like driving fast. I couldn’t
drive as fast if there weren’t good roads. Now that’s not to say that every
team needs a highway with this system that’s been
placed here and is very difficult to move. It’s a rigid structure, right? You get performance benefits
from the rigid structure. But you can’t say, whoop, we
don’t want to go that way anymore, we want to go over
here, without spending a lot of money to change
the process. So there are other
kinds of roads. Same general idea. There is a path. It’s now easier to go that way
than going through the jungle. But you can’t go 90 miles
an hour on this road. You don’t have to follow the– there are no lanes. Drive wherever you want. More flexibility here, but you
may run into accidents. You may hit someone
who is also on the other side of the road. So process is this very,
really a broad term. And when you’re thinking about
to be effective in getting stuff done with other people, no
matter how smart they are, you have to be thinking
about, well, how does our process fit? What things can we add
to the process? And how are we going to shape
this whole landscape so we’re able to be effective? That’s what process is about. Now people fear process
because– like the example of the highway,
you can look at a highway system as
loss of control. If you’re thinking, all right,
I’m in a SUV, right? I want to go in the mountains. If I’m on the highway, the
highway prevents me, or makes it difficult for me to go
up in the mountains. It is restrictive in a way. If I’m not going in the same
direction as everyone else, then process will prevent
me from doing stuff. A lot of people feel that
it trivializes your job. Once there’s a system for doing
something, it prevents you from applying your maximum
intelligence to the thing you’re trying to do, because
there are now these barriers in place. In lots of cases, I think, at
some point in our lives we have a bad experience with a
process being inflicted on us that was poorly designed, that
didn’t match what we did, and wasn’t implemented trying to get
the maximum value out of who we are. I can think of lots of stuff
in elementary school that fits into this. You can think of lots
of stuff in some– I don’t think this happens
often at Google, from the people I know who work here,
that I’ve talked to. But at many companies that’s
what having a job means. That you’re a cog in a wheel. And you fit into some structure
that isn’t designed to make you as efficient
as possible. It’s designed to make
you to be one more cog in a larger structure. So one example from IE that I
can share with you is, we had this big process battle about
check-ins, code check-ins. This affected the whole team. Every time a developer wrote a
piece of code, or fixed a bug that checked something into the
build, we didn’t have any real process for it. So to check it in– we
had source control, so there was that– but, in terms of the team there
was no structure for communicating it, tracking it. So the rule was, you check
something in, you send out mail to check in alias, which
most people are on. It goes out and if people have
questions, they ask you. It never really worked. Once we got beyond this tiny
little 10 person team it didn’t work any more. There were too many people,
too many people doing too many things. So the test team, or quality
assurance team, ended up wasting a lot of time. Because things that get checked
in that hadn’t gone through all the steps that
need to be gone through. There is no one verifying the
check-in before they happen. So lots of wasted effort. As the team got bigger and the
pace of our work got faster, complaining increased. By the time we got to IE 4.0
it was just a disaster. People would take their
check-ins and, instead of checking in little pieces as
they went along, which is a healthier way to do it, they
would batch them together. Because then they only had
to do the check-in once. va-doomp and then the whole
build would go bvfff, because these huge check-ins
where coming in. Finally, finally the builder,
the guy who was responsible for building, he had to
integrate all the components, got so sick of this, he went
and made a little web tool. The team was resistant. We had talked about it, but
everyone was afraid of too much process. Don’t restrict us. Don’t hold us back. So he went off and did it. He showed it to a few of
his friend developers. They started using it. It was just a beta,
just a side thing. And, within a week, everyone
said, that’s the way we’ve gotta do it. Why didn’t we do this before? This is so much better. I spend less time
checking in now. I spend much more time
writing code. Just an example. I’m not saying there’s something
wrong with your build process. I’m not saying you should
make a web form. But what I’m saying
is that there tends to be this pattern. Resistance to process,
resistance, something so awful, and then finally people
give in and try it. And then they’re like, what
were we complaining about? This is so much better. Related to fear of process is
smart people and how to organize them. Now it may be hard to believe,
it may be hard to believe, but there was a time when Microsoft,
around the time that I got there, had the
reputation for being this wild, fun, organic
place to work. You came in, you had
your own office. You could work on whatever
you want, it’s free. That was, at least,
the stereotype. That was the model everyone
thought, good place. So as a manager I was taught,
OK, if you’re going to manage smart people and creative people
you have to understand. You have to understand the kind
of environment they’re going to want to work in. There’s lots of evidence that
smart and creative people, they like to define their
own boundaries. They don’t want to be told where
they should stop, where they should start. They want to figure that
out for themselves. They tend to prefer working
with other smart people. Like people, people of kind A
like to spend time with people of kind A. They want to be able
to go as fast they can. They resist structure and like
to learn things on their own. All right, so what does this
mean if you are a manager of a corporation, you are the
manager of a team? You find a bunch of smart people
that are willing to work on something. What do you do? How do you organize them? Well, you start out in the
simplest way possible. You say, OK, you three
guys seem to want to work on that thing. Go work on that thing. You guys go over there
in that corner. You other three guys,
you go over here. Last three, you go there. Go have fun. We’ll figure out your
goals as you go. Go make some stuff. And we’ll worry about
integrating it when we get to that point. Great, excellent. Then time goes on, some of these
little things do well. So you get more people who
are working on these little piles of stuff. And there’s no rules, there’s
no structure. There’s just self-organization,
right? So you keep going. Time goes by, you’ve got
10, 8 little groups. It’s starting to get a little
bit different now. If you are a manager, or if you
are someone who’s trying to look at the whole picture,
it gets a little bit hard to fit things together. Because these guys are
speaking German. These guys might be
speaking French. These guys are trying
to do Esperanto. Is it Esperanto? Right, anyone know what
I’m talking about? AUDIENCE: Yeah. SCOTT BERKUN: OK, for the rest,
if you don’t know what I’m talking about– pretend
I said something really clever, and then– Now, when you’re at this view,
you’re starting to think– at some point, after six months,
after a year, you’re going to start to think, OK. We’ve got these 10 teams,
really smart people. But there is only certain
pockets that have been paying off for us. Either paying off in terms of
value for customers, paying off actually in revenue, paying
off in developing technologies that are adopted
by others, however your organization defines success
and defines payoff. There is only certain
areas that are really paying off well. So you have to start to think,
all right how do we maximize the resources we have? We’ve got these smart people
who are doing stuff that’s interesting, but it’s
not helping these core pillars things. So then, you say, I’m not
going to worry about it. It’s not a problem. We’re doing well. Then nearly a year goes by, six
months go by, you’ve got this big system now. And you can clearly see that
30%, 40% of your smart people, they’re not directly
contributing to these things. So, eventually you
start to say, all right, we need to focus. We need to figure out how we can
get these smart people who aren’t being as maximally
effective to what we’re trying to get done as possible. And how do we move
them around? And you try to bring them so
that they’re closer, maybe not fitting all the way, you
don’t want to pbth. You don’t want to put
them in a hole. But you’re trying to say, OK,
you’re kind of working on this sort of thing. These guys are doing that. So we’re going to organize
you sort of towards them. So going back to the beginning,
when you’re starting out and you’ve got
nine people organized into three units of three, versus 120
people organized into six units of 20, the way you think
about what efficiency means, or what effectiveness
means, or what value means is different. It’s not fundamentally
different. It’s not, you should say these
people are now working on an assembly line. But your scale, when you start
thinking about the scale, it changes how you measure value. It changes how you think
about what a good decision looks like. So once you’re in an
organization that’s big enough, and you have these
really smart people who initially, at the beginning you
felt, great, you’re smart, you’re motivated, go do it. When you get to this point,
these things start to stand out more. Not that they shouldn’t
be there. But they need to be there with a
better reason than why these guys were there. And this is natural. I don’t think there’s anything
evil about this. It’s just even if all these
people are brilliant, you end up when you’re thinking of,
OK, I’m the CEO, I’m the manager, I’m the team leader,
the way you look at these things changes. Just as an example, just for
fun, I went back through the Wayback Machine. This is an archive, the internet
archive, and took a look at Google. Now I actually think
Google does a great job, the main website– you’ve done a great job of
minimizing the effect that kind of like, OK, group A, group
B, group C, we’re going to– this stuff is exploding
and expanding. But you can see the same kind
of thing happening, just by looking at the– I don’t know how Google’s
organized, but I’m guessing that that kind of thing is
starting to happen already. So this is from ’98, and 2000,
more stuff got added here, advanced search and
preferences. 2001, we now have the
introduction of tabs, ta-duum the tabs are there. And advance preferences,
language tools, a fifth tab, news, New! I think we skipped one. Yeah, fifth tab. News is not new anymore. It’s still there, though. It did well. It earned its wings. Then in 2004 there
is now more. More, dreaded more, OK? Because now there’s– we’ve got this. Google is not just this
little thing anymore, I’m guessing, right? Smart team of people, little
bunch of people, images, bunch of people, groups, news, more. More, OK. Now all full of people, right? And this was yesterday. You’ve got more. This has changed, now. Because there’s so much stuff
here, vroom, it’s bigger. So, if you were a UI designer,
if you were a manager, if you’re looking at the whole
thing now, you’re not as worried as much about getting
little teams of people. That’s not your primary problem
anymore, getting little groups of people
to do smart things. Your primary problem
is now, OK. Now we’ve got all these things,
what’s the best way to shape them, organize them? From a user-interface
perspective, but also from an internal, organizational
perspective, it changes the dynamic. So Internet Explorer, just to
bring this back to the browser war stuff and stuff I supposedly
learned, IE 2.0 was this stupid little thing. It was this stupid
little project. HTML was just a markup
language. You know how many markup
languages there were? OK, we’ll make one. You 10 guys, you’re smart,
you go over there. Then two years later, it was
being called a platform, a development platform. It was just ridiculous how
much attention was being paid to this. And, at the time, one of the
back story things– if you pick up either of those books,
you’ll read about this. In 1997, Brad Silverberg was the
VP for the division I was in, the Internet Platform
Tools Division. And the plan that he was
pushing for– this is documented in the book, I’m not
giving out confidential information– the plan he was pushing for
was to make HTML and the Microsoft browser a platform,
and to move away from Windows. That’s why there’s a Unix
version of IE, there was a Mac version, other versions
were planned. And we’re going to move on. Windows we’ll leave behind. And the big battle at the
company at the time was whether we should really
be doing this or not. Jim Alton, according to the
book, I’m not telling you this, the book is telling
you this, Jim Alton was saying, Windows. Windows is a $3 billion
franchise. you can’t bet against a
$3 billion franchise. I mean, how many of you can bet
against a guaranteed $3 billion a year, right? I don’t know if I
could do that. So he said, you can’t do that. They argue, they argue,
they argue. Apparently Jim Alton won
and by IE 5.0 this team was lopped in half. And the browser became
just a browser again. And all the people who were
thinking about a platform went back to Windows. Sidebar is done, let’s get back
to what happens when a team grows as much. Communication doesn’t scale
as well as you’d like. Three smart people in a room,
five smart people in a room can go very quickly, can
communicate very effectively, at a fast pace. Once you get to 30 smart people,
50 smart people, it’s more complicated. Fred Brooks, in his book
Mythical Man-Month, has this thing called Brook’s Law, that
says every time you add a person to a team, the total
number of people, the total number of links in the network
of communication goes up, not arithmetically, but
geometrically. So every person you
add, this network gets bigger and bigger. So if you’re not paying
attention to how your team has changed, you have people are
still behaving as if they’re this local, simple,
little unit. But really they’re in this
larger system that is demanding a different way
or different style of communication from them. Some other things on here too. It changes the way your rewards
are given out too. When you on a big team, it’s no
longer about, hey, look at this great piece of
code that I wrote. Look at this great
thing I designed. It has to be about how this
thing contributed to the bigger picture. How this thing you’re
working on makes the whole thing work better. So the dynamics change. So the purpose of specs, whether
you write them or not, there’s a problem that needs to
be solved on those teams. And the problem is that before
decisions are made, before 10 people, five people, or three
people spend a week working on something, you want other people
to have a chance to review the ideas and the
concepts before they’re built. Just basic common sense. Before you go and you build a
house, you draw up a plan. And you show it to someone else,
who know’s something about building. You say, look at this. You see any problems with it I
should change before I spend $200,000 building a house? Now granted, writing code
is not building a house. It’s not $200,000. It’s not six months. Now granted, but your time
is precious, important. When you’re working on
something, you want to have some way to review your
decisions before they’re implemented. Also, if you’re working with
other people, you want there to be some understanding of
what you’re trying to do. Like, if you are in a row boat
and the guy in front of you is rowing in one direction, you’re
trying to row another direction, you’re not going
to get anywhere. Whereas you can both say, hey,
before we start rowing, let’s agree we’re going
to turn left. OK, both going to turn left,
now you’re off and running. That conversation, if you’re
building something more complicated than rowing a boat,
is a specification. So that’s what that does. That’s the real purpose
of specs. Now, you don’t always need to
write the thing down, but that conversation needs to happen. And the more people involved,
more people that are affected by what you’re doing, the more
important some kind of process for it is. I’m going to skip what
that slide says. Now the thing that
people really don’t like about specs– at least I think so– that they don’t recognize the
difference between the actual writing of the specification
and what the specification implies. So what most people don’t like
about specs is that when the time comes that you need to
write them, it’s because someone is dependent on
what you’re doing. That’s usually when
the need arises. Someone says, hey, John, you
know last time I worked with you, you built that thing and
you changed it the day before it shipped. And all the documentation I
wrote was completely useless. So this time, can you
talk to me before you make any changes? OK, how about even better,
let’s agree on what we’re going to build. So when I start writing
documentation it’s going to match what you’ve built. That’s a dependency. Someone is dependent on
what you’re doing. When you’re starting off and
you’re a small team– for me, IE 1.0, IE 2.0– there was no documentation,
there was no localization, no one else was consuming
this stuff. But when the thing was
successful, people want to use the thing. Once you start calling yourself
a platform, people want to write to
your platform. You now have customers
that are depending on what you’re doing. So then specifications
reflect that. They force you to be
accountable to your dependents. So people blame specifications. Oh, I don’t want to document
all this stuff. But really they’re just
frustrated in having dependencies. So it’s important to recognize
the difference. Once you’re successful, the
longer you’re making stuff, it’s the same thing, the version
six of your thing, version eight, working on it
for two years, you will collect dependencies. I guarantee you. The more platformy you are, the
more corporate clients you have for your thing, you will
collect dependencies. And you’ll start to have to
honor those dependencies to continue to be successful. Eventually you may have more
dependencies than you can effectively manage. And you will have to struggle
to come up with a way to continue to innovate without
breaking those dependencies. On Internet Explorer we used
to have arguments all time about, specs should be
written this way. Or, there should be no specs. John, Sally, Bob and Tom are
smart, leave them alone. They’ll figure it out. Don’t write anything down. We had arguments about the
process and not why we’re doing the process. So if you think you don’t need
specs, you need to ask yourself, OK, are we
being effective? Are we managing our
dependencies? Are people getting what they
expect to get when we’re done? Great, OK, if you can answer
those questions without specification fine. But if you are having problems
with those things, specifications, some kind of
specification documentation, that’s going to be
your answer. Yeah, all your dependencies. OK, here we are, managing
and leading innovation. Can I get a time check? How are we doing on time? What time is it? AUDIENCE: It’s 20 to 12:00. SCOTT BERKUN: 20 to 12:00,
right on the nose. OK. Never thought a Microsoft
person, a former Microsoft person could be on time. That’s exactly the time I
thought it was going to be. OK. One secret to being on time is
not to tell people what time you thought it was. You see? It’s like a magic trick. I can say that I thought
that’s what it was going to be. Now where were we? Innovation is not
a holy grail? I have no idea what
that means. Oh, I got it, I got it. So here’s the deal. So “innovation” is a
word that comes up a lot in our industry. Oh, they’re so innovative. Fred, he’s the most innovative
guy I ever met. The world “inn-o-vate” has a
very specific, real meaning. It means change, it means doing
something different. We assume, in our industry,
it’s like this underlying assumption that innovative
means better. But it doesn’t. Lots of things get heralded
for being innovative, even though they’re actually worse
than what was there before. We believe in innovation even
when we have evidence to the contrary that it’s actually not
going to be useful to us. So what you really want to be
focusing on is progress. Is this thing better than
what we had before? That’s what’s important. And you can be better without
getting an award for the most innovative idea of the month. Being better can often
be very pedestrian. Making lots of little, simple
improvements that, collectively, make something
much better. If you disagree with me, if you
don’t believe me, or if you’re told to innovate anyway,
innovation doesn’t guarantee all the things
that we like to believe that it does. Having an innovative design
for something doesn’t guarantee that it’s going to
do well, that it’s going to make customers happier, that
it’s going to sell more, that it’s going to improve your
technological infrastructure. There is no guarantee. Because innovation is change. And it’s risky. When you do something new,
you’re not really sure of all the effects it’s going to have.
Hard to predict when you’re changing stuff. The only other point on
innovation I’m going to make is that there’s a lot of
evidence, at least in the business sector– I’m not saying that what
wins in the marketplace is going to be better. Or that your only goal in life
is to win in the marketplace. But if you’re looking at the
history of business, in the technology business there is
a lot of evidence that the second wave tends to win. That being first, and being
the innovator doesn’t, historically, set you up to be
the person who after five years that’s still going
to still be the leader in that market. There’s a good book, that used
to be very popular at Microsoft– while I was there, don’t know
if it still is– called The Innovators Dilemma, which is
all about these first wave, second wave kind of trends. The game company
Atari comes up. They were the first to do
this home game thing. And then Nintendo just kind of
blew them out of the water. Hayes modems, anybody remember
Hayes modems? Right? They used to be like this 90%,
monopolistic kind of success. And then within a few years
they were destroyed. There’s lots of examples about
why that happens, and some suggestions about how
you manage that. But innovation is not
the holy grail. What you want instead is
directed innovation. You want to be able to say,
here’s a problem that we know we want to solve. We’ve identified that
our customers suffer from this problem. We know that we can make money
from this problem. And we think we have the
technology that will let us build something that solves
those things. Let’s innovate here,
this thing. You don’t want innovation to
be a Buckminster Fuller, Einstein-ian, I’m just
going to be smart and just come up with– that’s closer to research. Directed innovation is the
thing, when you have the skills to make new products and
new ideas, that tends to be the sweet spot of
creative thinking. You start off by coming up with
some specific thing you know you want to achieve that
might be achievable. You define that, and then you
direct your innovation towards that thing. So I just have some examples,
a car that gets better mileage, a mousetrap that is
humane, effective, and easy to use; a beer that has some
certain set of characteristics that you think is important. And once you have that, the
way you do directed innovation– which is something that I
experienced for the first time on IE 4.0, I’ll talk about
that in a second– is you come up with some
period of time. You say, all right, here’s
our schedule. Here’s the amount of time we
have to explore different ideas for this thing. Here is the amount of time,
after that, we have to refine the best ideas we found. And at that point we’re going
to make decisions. And we’re going to build
something and ship it. So you end up with something
that looks like this, where you have some space
you’re creating. I’m saying three weeks, but
that could be any number. Explore alternatives, narrow
down alternatives. You started there with a
specific problem you’re trying to solve, you end up here with
a single definition for what you’re going to build. Then you go and you build it. And during that time period,
hey, you’re innovating, you’re coming up with all kinds
of different ideas. But they’re bounded by some
problem definition. It’s big enough to give you room
to innovate, but you know you’re not going to be thinking
about new kinds of you know processed cheese, or
new nuclear weapons systems, or something, right? Because you know there’s some
framework for what you’re directing your innovative
powers at. I actually don’t have time to
talk about this, so I’m going to skip it. The last thing that I was going
to talk to you about is about trade-offs. Oh, I should mention– OK, I do want to talk
about that slide. So on IE 4.0, IE 4.0 was the
first time we had a big enough team, we had enough resources
that we could innovate. We had chartered a new platform,
integrate the internet and desktop software,
that was our charter. So we tried to do this thing
that I described. We tried to do this new thing
where we brought in– we dedicated time to exploring
ideas and refining them. But we had never worked
that way before. We were used to working in
this very ad hoc manner. So what this diagram shows– I didn’t make this diagram, a
woman named Virginia Satir has this diagram– and it’s about change, how
humans respond to change. You change a process, you change
a system for how things are done, this is a
chronology, from a psychological perspective
of what tends to happen. If you’re starting here, time
goes by, and this is three months further along than when
you started over there. And what this show’s is, at
the beginning you’re at a certain level of quality
performance, ability to get done whatever you’re
trying to get done. You introduce some kind of new
element, we are going to do direct innovation, because
Scott said so. OK. Great. The team starts doing that. Once you ask people to work
differently, there tends to be some fluctuation in their
level of performance. Because there’s new things
they have to do. There’s new people they
have to talk to. There’s differences in how
they get stuff done. They’re unfamiliar, they’re
going to make mistakes. And the level of performance
tends to fluctuate. At some point, hopefully, it
reaches the point where the change clicks in and people
get how to be effective in this new way of working. And then performance improves. And now there is a new level
of comfortable status quo. But you’ve increased the
level of performance. So I show you this diagram not
because– it’s not strictly for innovation. Any time you make a change how
work gets done, this pattern tends to surface. If you were just to decide
tomorrow to start running five miles every morning, and you
started tomorrow morning, when you first did this, you are
going to suffer a lot, as you’re getting used
to this new way of getting up every morning. Right? But at some point your body
will adjust, you’ll adapt, you’ll start to like it, you get
coffee earlier, whatever. Transforming idea to get to a
point where you have a new status quo. So for me on Internet Explorer
4.0, we changed so many things at the same time, we’re doing
this directed innovation thing, we’re chartered with
being a platform, no one knows how to do that, right? For me, my memories of IE
4.0 are all in here. That’s what I remember. I don’t remember much
about that. And I don’t remember
much about that. I remember we did this. We got things a little
bit better. And we shipped. And then for IE 5.0 five
we just totally– we had like our wave
of conservatism. We had so much trouble working
on IE 4.0 with all the change we made, that we pulled back on
lots of aspects of how we got work done. If there are questions, I can
talk more about what happened on IE 5.0, but my point to you
is that even if you’re doing something smart, you have an
improvement that you’re making to a project, a way of working,
a system of working, even if it’s just for yourself,
or for your team, that you’ll tend to see
this pattern happen. And you have to have enough
confidence in the change that you’re making that you’re going
to see your way through some initial chaos and not bail
out and say, you know what, you’re right? We shouldn’t write specs,
or whatever. So the last thing I’m going
to talk about is about trade-offs. There are certain fundamentals
that surface again and again when you’re making things. It’s not just software, when
you’re making anything there’s certain fundamentals that
you will encounter. The project manager one– this
is like project management textbook 101 stuff– is time, scope, quality, and
cost. Anytime you’re working, if you want things to be higher
quality, you have to pay for that with
higher costs. If you want things to be done in
less time, you either have to narrow your scope or
lower your quality. Inter-related, trade-off between
those variables. From a different perspective,
when you’re thinking about design or you’re thinking about
direction or strategy similar trade-off between the
business, the customer, and the technology that
you’re using. There’s this diagram– oh, not a diagram. Story about IE 4.0. This is a screenshot from
Internet Explorer 4.0. For those of you who never used
Internet Explorer 4.0, or turned all this crap off, which
I was one of, this is a major investment for us. This is called The
Channel Bar. And what happened at the time,
this is 1996, ’97, we’re told this is a platform, the
industry, Wired Magazine, “push” technology, new platform
for doing stuff. So we invested so much energy in
figuring out, how do we get businesses, other businesses, to
pay us money for placement in the real estate that we have
value in, the desktop? That’s what this is. So these companies did
deals with us– MSNBC, Disney, Warner Brothers,
the other ones aren’t filled in yet,
but we made deals with all these companies. Because we felt this was the
future of Microsoft. This was the future of the
industry, advertising, something you guys are very
familiar with, right? This was 1996, so no one knew
what the hell they were doing with advertising. This seems ridiculous now, but
everyone else was doing equally ridiculous things. But my point is, we made a
trade-off, we went for the business first without thinking
about the customer. So we put this together. And we said, all right, we’re
going to put this here. What does it do? Hm, not really very much. You click on these things it
was supposed to take you to this special, updated version
of their website. Custom made for this platform. But it turned out that there
really wasn’t much they could do there than they could do
on their own website. So we had this whole business
model set up that had no customer component
to it really. There’s no customer value to
want to go to the desktop to look at this thing
when they could just go to these websites. So my point is that you always
have these three trade-offs. These three ways of looking
at doing anything. The technology view,
what can we build? What would be cool to build? How can we make it? The business view, where
can we make money? How can we make money? How much money can we make? And the customer view, what
do people need to do? How are they going to do it? What problems do they have
that we can solve? Combine these views together. If you’re smart, you’re
working here. Where you are building
technologies that are going to generate money, and you’re going
to satisfy customers. Synergy, you’ve got this
nice sweet spot. What we did on IE 4.0 was we
spent a lot of time here. Really didn’t have a story
straightened out for what customers were going to do, what
push was going to help people do. but we didn’t
let that stop us. In part because the industry
was stampeding in this direction and we felt
we had to follow. But my point to you is, you’re
always looking at these trade-offs. And if you’re smart when you
come up with a new idea for technology, you say, hey,
this is so cool. Your next set of questions have
to be, OK, who’s going to use this and why, other
than other developers that think it’s cool? Which if you’re making
development tools that might be enough, because that’s
your market. But if you’re trying to reach
a wider audience, what are they going to do? How is this going
to help them? And second set of questions,
OK, got a technology, got stuff that we know people need
to do, the technology will help them with. How do we monetize this? How do we make this work? These concerts are
very fundamental. You guys probably have
conversations like this all the time. But I had never seen a diagram
like this until a few years ago, that helped me whenever I
was confronted with a business person who only thought about
this part of the world. Or if I was confronted with an
engineer who was only thinking about this part of the world. Laying it out this
way shows, oh. So having a good business idea
that customers might like, but we can’t build, isn’t good. Some marketing people spend
their time here. Oh, we don’t worry about that. We don’t need to worry
about that, right? You have some technologists that
spend their time here. Which is a nice place to spend,
you can think of all the open source software, free
software, that’s here. And that’s great too. It all depends on, looking at
this framework, what the goals of your organization are, and
how you are going to make it all fit together. OK, so I am done with– I’m going to wrap up here, and
then I’ll take questions. We have about 10 minutes,
12 minutes left. Every team and every project
is different. So you come in the door– you could also, if you’re more
philosophical, you could say, every day is different. You come in every day, the
world is a little bit different, people are
a little different. If you’re paying attention,
people who are effective tend to be ones who are
paying attention. What is different now? And how am I responding to
today, instead of how I want today to be? Process is not an evil thing. You have a process you’re
using, no matter what you call it. And if you’re thinking about
how to make your team more effective, how to make your team
happier, how to be more effective yourself, you’re
thinking about processes. Who do I talk to? When? What decisions do I make? How do I make them? I talked about smart
organizations, this bird’s eye view. Lots of little, small teams,
then once you’ve got 10 small teams, you’ve now got a
different set of problems. As organizations grow, you start
to have to deal with a different kind of working
structure. And the last thing I mentioned,
it was about trade-offs. If you’re really going to be
effective at making strategy decisions, direction decisions,
you have to see those three circles. And be working with other people
who are agreeing on the same place in those three
circles that you are trying to target. So with that, I will– Oh, just the last thing
to wrap up. So if you liked anything I said
today, if you want talk more about it you can feel
free to send me mail. I’ll be at the brewery tonight,
drinking beer. So if you like beer, you’re
welcome to come. I’ll buy a beer. There’s a free chapter
of the book. So the stuff I talked about
towards the end, the business technology, about how to
figure out what to do. There’s a free chapter the book,
it’s available, it’s all about that level of stuff. If you go to scottberkun.com
you can find the free chapter up there. And open the floor
for questions. Yeah. AUDIENCE: It seems like the
place where IE added the most value both to the customers and
innovation for developers as well was the introduction
of HTML. Could you talk some about both
where the ideas came from, the technology? There was this discussion
about this thing called [? Kyro, ?] how that
led into it? And also the strategy there was
this notion of beating the pants out of Netscape with
that one feature. SCOTT BERKUN: OK, the question
was, the HTML was one of the key innovations of IE. Just talk about how it was
developed and what the strategy was. Internet Explorer had several
sub-teams that all felt that what they were doing were the
key thing, that was going to make the difference. So there was a team that was
called the Trident Team that was responsible for
the DHTML engine. It was one of the biggest
teams on the product. That team came from a group in
the company that had been doing forms engines. A forms engine is a tool, and
it’s like a piece of Visual Studio or Macromedia
Dreamweaver, it lets you do form layout. Microsoft has a lot of
experience in doing forms engines stuff. So to the people who worked
on DHTML, it seems like a no-brainer, Microsoft knows how
to make development tools for doing forms layout. There was a team that was
doing a different forms technology. That team came over and
became the DHTML team. So a team that already knew
how to do that stuff. So the thinking was, we know
better than most of the companies in the world
how to make forms-type development tools. The fact that it has to be done
in the HTML thing, we’ll figure that out. But that was the first step. In terms of the actual choices
that were made in DHTML, I wasn’t a program manager on
the DHTML team, so I can’t give you what their thinking
was at the time. But it was about horsepower. Trying to make as much
value out of the platform as you could. And present that to developers
and let that be the way that you got adoption. Have more functionality and
more value for developers. Does that answer
your question? Or close? AUDIENCE: That’s part– I guess it seems like there is
probably a big story in there. That feature was really
difficult for Netscape to copy, to replicate. It took them years to really
fix that, deal with that. SCOTT BERKUN: But I think the
key thing was this technology that Microsoft knew very well,
how to make forms, tools for developers. So there was an advantage
that– I think that was the primary
thing, it was a strength that Microsoft had in the company,
took it and said, go add that in. And a team that already
knew how to do it. Other questions? Yes. AUDIENCE: In your diagram with
the business technology and– I’m curious, what was the
situation with IE, [UNINTELLIGIBLE PHRASE] Windows? What was the business–? SCOTT BERKUN: Yeah, let me– I have a few books
to give away. I’ll give them to people
who ask questions. Here you go, sir. Since you weren’t happy
with the answer, you at least get a book. Strategy for being free? AUDIENCE: Well, just that the
technology side and the customer [UNINTELLIGIBLE]. SCOTT BERKUN: As soon as it
became a market share battle, it’s a market share battle,
giving away stuff for free is an ancient method
for competing. I’m not saying it’s a good
method, or fair, or not. But it is a old method, right? You give stuff away until you
get enough people exposed to your thing. And eventually they’re willing
to pay for it, or used instead of the other guy. I don’t think it was a brilliant
strategy, it’s a basic strategy. If you’re the new pizza shop in
town, you’re going to give stuff away for free. Just heavily discounted,
coupons, grand opening, right? It’s the same basic idea. Other questions? Yes in back. AUDIENCE: When I was at
Microsoft, just six, nine months ago. There was almost no one working
on IE any more. What happened to morph IE from
something that hundreds of developers were working on
to absolutely no one? SCOTT BERKUN: My
understanding– I left the IE team in 1999, so
right before version 5.0 shipped, I had moved on. So that was before the
team disappears. I don’t know the full story,
but I can tell you my impression. My impression was that,
the war was over. We have that 200 Marines, we’ve
won, the flag is in the ground, other battles to fight,
get these Marines back in the field. That’s all it was. There was no incentive. I’m putting my telepathic hat
on, I don’t know this for sure, no one showed me. There was no incentive to
continue investing as much money and resources into
continuing to develop something that wasn’t a
competitive issue anymore. It’s a conservative
view of the world. We’ve won. We’re not concerned anyone’s
going to be a threat, let’s move on. And that’s what creates the
window for a Firefox, right? There was a huge window there. Nothing had happened on
IE for four years. The battlefield is empty. That created the opportunity for
what’s going on now, which I think is great. That’s my understanding. 300 people, it was expensive,
expensive. 300 people is a lot of people. Put them on something that’s
going to help us with the next thing that we’re
worried about. Yeah? AUDIENCE: Did you use Microsoft
Project to manage the budgets? SCOTT BERKUN: No. [LAUGHTER] SCOTT BERKUN: Very
few people– there weren’t that many teams
at Microsoft, in my view, people I came across,
that used Project. I think you had a handful of
people that were like the integrators, the people who were
thinking about how to get these 20 component teams to line
up, they used Project. For people who were more feature
developer managers, like myself, we’re building
stuff, we were less worried about the huge integration
tree. No, it was much more informal. Some people would use it, but
it wasn’t something where you’d pass around project
documents all the time. The project team uses Project. But most other teams didn’t. Now at Microsoft there’s not– no one tells you, at least when
I was, no one told you how to use any particular
tool. And most Microsoft teams tended
to think that what everyone else was
doing was bad. So there’s a lot of like,
the Windows team? We’re Office. We know what we’re doing. The Windows? So it’s not surprising
that people weren’t using these things. Other questions? Yes, sir. AUDIENCE: I heard that
Dev Studio was an exception to that. You were forced to use Dev
Studio and that’s why Dev Studio happened to be
so good, right? SCOTT BERKUN: I don’t know, I
don’t have enough experience to give you a confident
answer. I’d say that it was– there weren’t that many other
development tools for C, C++ stuff on Windows anymore,
Borland– there weren’t that many
tools around anymore– I don’t really know. Yeah? AUDIENCE: That is the way that
I heard it, was that Dev Studio was bad until Microsoft
was forced to use it themselves. And it became– SCOTT BERKUN: Well, Microsoft
does get involved in the culture that, especially if
you’re in the organization, that you use it, and– but that doesn’t mean that once
a thing is done, you’ll continue to use it. Other questions? Yes, sir. AUDIENCE: What chance
do you think Firefox has at beating IE? SCOTT BERKUN: I think it
has already beaten it. It’s a much better product. Hands down, there’s
no question. You mean in terms of beating it
in terms of market share? I think you have to
look at the– there’s so many battlefields. There’s the consumer
battlefield, individuals who download stuff. That’s why so much of Firefox’s
success is with the development community, people
who are choosing on their own. But when you want to get past
10% market share to 40%. You’re talking about General
Motors, you’re talking about Safeco, you’re talking
about companies who have 30,000 desktops. And one person is going
to make that decision. And it’s a whole other
ball game. Now you’re talking about
total cost of ownership, upgrade costs. It becomes a different thing. So for Firefox to– it depends what the goals are. To be the market share
leader, it’s going to need corporate adoption. You have to sell the
corporations differently. Microsoft is like IBM used to
be, it’s a very safe choice for people to– oh, I’ll
use Microsoft. Well, no one is going to fire
you for making that choice. But to go and use this
new thing, this startup, open source? It’s a different dimension. But it’s a better product
though, so that’s going to help ease all of those things. Yeah? Is there another question? You had one before, right? AUDIENCE: Yeah, well my question
was, can I have another book
[UNINTELLIGIBLE PHRASE]? SCOTT BERKUN: I have two left. Hey, it depends on how good
your question is. AUDIENCE:
[UNINTELLIGIBLE PHRASE] all other the other questions
[UNINTELLIGIBLE]. SCOTT BERKUN: Got it. Go ahead and ask
your question. That was your only question? Oh, come on. I’m sorry. I can’t condone that. I can’t allow that to happen. I’ll give you a chance to come
up with another question. Blue. Yeah? AUDIENCE: I’m actually curious,
between ’93 and when you left, obviously a lot
of things have changed. How do you think, how much has
middle management changed? And how much do you think that
impacted the overall direction of the company? SCOTT BERKUN: That’s
a good question. The first thing I will say is
that, while I was there, every group at Microsoft was very
different, very different. The external perception, which
is probably something you guys feel, everyone thinks, even when
I was there, Microsoft is you know, Borgs. Everything is the same, you wear
the same shirts, you– My experience was totally
different. Every group had a lot of
autonomy and worked very differently. So, towards the end, after I
left, I think that it’s become more systematic. It’s still different, you go to
the Office group and it’s a very different way of working
than in Windows and in the Developer Division,
than in the Xbox it’s still very different. It depends on where you are. But, on the whole, the company
has continued to grow. I left, it was probably
40,000 people. It’s now 60,000 people. When you’re at that scale– I talked about some of the
factors here– the way management works tends to
go towards bureaucratic. It tends to. So I would say it’s more
bureaucratic, more conservative, harder for
executives who wanted to do something radically different,
harder for them to do it than it was. It’s still probably better
than the Fortune 500, I’m guessing, not that I’ve worked
there, it’s probably better, but it’s worse than
I remember it. But, from what I’ve learned, I
think that’s just the nature of companies getting bigger. You will tend to see more of
that as you get bigger. Not always, the better your
management, the better your CEO the more you can protect
against that. But as you get bigger,
you will start to see more of that happen. It’s just the law of averages
or something. Other questions? Good question. Yes, sir. In the front. I’m out of books. AUDIENCE: That’s all right. Just a quick question. Did the emergence of Java in ’95
have any impact at all on [UNINTELLIGIBLE PHRASE]? SCOTT BERKUN: Oh, yeah. That was at the beginning. And that was one of the things
that everyone said was– there was certainly a perception
that that was– they said Navigator was
the end of Microsoft. They did. Having been there, they said,
this is the future. You don’t care about
desktop anymore. They said the same
thing about Java. Java had the same potential
to be vrrrew, just everything was gone. So Microsoft was very
worried about Java. And there was lots of talk
about, maybe the whole balance of this effort should be under
this Microsoft Java effort. And where the job effort should
live bounced around in the company. Should it be part of development
tools Division? Should it be part of
the platform group? So there was a lot of
fear about Java. I didn’t work on the group
that worked on Java. There should be a
book about that. Because that whole Java, Sun
version of Java, Microsoft version of Java thing, the
tactics for that whole thing was very complicated
and very nasty. I don’t know the details
of it though. But that would make for a better
book than those two that I read, I think. Yeah, in the back. AUDIENCE: How would your
philosophy be different if you were still at Microsoft? SCOTT BERKUN: Oh, that’s
an excellent question. I don’t think that it would
be much different. I think, I probably would have
to think through who I know– like what I said at the
beginning, I would have to think through who I knew, that
was there at the same time, and make sure I wouldn’t end up
upsetting anyone was in the room, at least. But there was
nothing here to– some of this stuff I’ve said while
I was there. IE 4.0 was a very
interesting case study for lots of reasons. Lots of weird stuff
happened on it. So I’ve talked about
it there before. Off the top of my head,
I don’t think I would change very much. I think if I was talking to
Microsoft I would probably go into more dirty details maybe. Because it would mean something
more to the people. People would know the
references better. This, I knew I was talking to
an outsider audience, so I tried not to talk– I didn’t use any VP names, or
manager names that people wouldn’t know here. Yeah. AUDIENCE: You said that they
dismantled the IE team because they won the war. OK, so they won the war on– SCOTT BERKUN: That’s
what I think. Don’t get me wrong here. Nobody told me that’s
what they did. That’s what I think happened. AUDIENCE: [UNINTELLIGIBLE]
won the war on Windows [? in Office 2.0 , ?] where is the current war? SCOTT BERKUN: They won the
war on Windows in IE 2.0. There’s lots of wars, right? There were lots of wars then. Just look at– Microsoft is such
a big company. Microsoft wants to be like GE. They want to have interests in
so many different businesses. Like General Electric makes
refrigerators and jet engines. Microsoft wants, and is,
wants to be like that. So video games is one. Xbox is a trailing
market, right? Then you have the whole search
engine thing, which Microsoft is trying now, for the seventh
time, to try to get involved in. Then you have the whole
advertising end which Microsoft is doing a better job
of now through MSN, better job than they’ve done
historically advertising. You’ve got the home, Sony. Microsoft has a thing
for Sony, they to compete with Sony. So eHome, getting control over
the other entry points into the whole, how you
use technology. There’s just lots. If you went through the division
list, there was like seven major divisions
at Microsoft. There is a war for each one. And Microsoft trails
in most of them. Or they’re second or third,
or worse in most things. AUDIENCE: [INAUDIBLE] SCOTT BERKUN: I’m sorry? AUDIENCE: Have they decimated
the Windows team? SCOTT BERKUN: No, no, Windows
team is a core business. Windows team and the Office team
generate 80%, 70% of the company’s revenue. So that’s a major foundation
of the company, Windows and Office. If you look at the financial
statements every year, it tells you how much revenue
each group generates. So I’m not telling secrets. So Windows and Office– Other questions? About–? Microsoft project manager. Writing a book. Beer. Well, thank you for coming. [UNINTELLIGIBLE PHRASE]. [APPLAUSE] SCOTT BERKUN: Thank you.

10 thoughts on “Lessons Learned from the Browser Wars

  1. cool dude
    OS war microsoft kicked apples ass
    browser war microsoft won
    een if apple is still here Microsoft got over 90% of OS market

  2. While not mentioned, this talk can be a precursor to any discussion of introducing agile development methodology, like SCRUM. It also touches on a few "truths" as to why SCRUM is great, but should also be adapted so it works for your team.

Leave a Reply

Your email address will not be published. Required fields are marked *