view release on metacpan or  search on metacpan

share/SpamAssassin/easy_ham_2/00693.2183b91fb14b93bdfaab337b915c98bb  view on Meta::CPAN

the Longhorn wave, Yukon wave, or the .Net wave and really have enough
time to have some cross-cutting discussions about how we make that happen.

Bill [Gates] is dedicated full-time to being chief software
architect. He also happens to be chairman of the company, but he spends
most of his time being chief software architect. We have a body now that
meets every month -- the SLTT [Senior Leadership Technical Team],
basically the top people involved in the product-creating strategy --
and we present and discuss the issues. Bill is driving a process for
each of these waves. For instance, [he will ask] what are the
cross-cutting scenarios that I want, and then [he will] get all the
right product groups together and bring these things in front of the SLTT.

People talk about what it takes to be a good manager, and people talk
about being a good coach and getting people to like you. In a large
organization those things are important, but at a certain level, ... the
most important thing you can do for your people to make them better is
to give them a framework where they can work in harmony with the other
people in the company. And from Bill's perspective, [this framework] is
the technical road map and the SLTT process; it is the scenarios. From
my perspective, it is the P&L [profit and loss] structure and the
multiple businesses because, given how we work, giving people a
framework that gets them to make the whole bigger than the sum of the
parts will mean we have better offerings.

> It seems the scenarios construct is really working for you. Is this an
> evolution of the solutions approach? 

I would say it is a pretty direct extrapolation from the solutions
stuff, only I think we are just getting a little more experience. I
think we use the word scenarios more often and solutions less, because
solution sounds more like a fixed thing. At the end of the day, most of
the things we do are customizable and programmable, and so people make
them into the solution they want. But they are still scenarios. What
will software deployment look like? Well, that is a scenario because it
involves Windows, Office, and other applications.

We are working hard to make sure the whole is bigger than the sum of the
parts. That's not to say people are always comfortable with this. I
can't even say we will do it perfectly. All we have to do is do it a lot
better than we had been doing it. I think that would be a big step
forward for the customers.

> Will this approach cut down on some of the technology civil wars
> Microsoft has had in the past involving who is going to gain control of
> a project? This seems to be a very democratic approach to development.

I would not use the word democracy to describe it. People have to come
together and ultimately make some decisions. This is not a voting
process here, the agenda of what we think is important. We get a lot of
input. [But] once it is decided, people don't get to vote with their feet.

We try to make a quantum leap here in terms of our ability to improve
pulling together all the pieces. Our customers want us to do
that. Simplifying concepts by unifying them. The customers don't say
they want us to do that, but when we do do that, they go, 'Ahhh, I get
it. That makes sense.'

I don't want to go to six more meetings where people say, 'Is your
workflow strategy BizTalk?' ... Or 'What's your Office workflow
strategy?' Or 'Why is synchronization in some ways better for e-mail and
Outlook than it is for file folders and Web pages?'

To get that sort of synchronization sometimes -- to get that high-level
road map to work -- you have to build something we don't have today. So
we have been talking about unifying storage. And so the best way to get
all this stuff to work is to get them all to work just one way. Then you
just keep tuning one set of parameters instead of having a thousand
flowers blooming.

> In your Fusion keynote today, you talked about who your competitors
> are, and it was the usual suspects. But one you didn't mention is
> yourself. You are competing against the last generation of your technology.

Always. Given that our stuff doesn't wear out or break down -- you can
question whether it breaks or not [Ballmer grins] -- but it doesn't
break down like machinery does. To get anyone to do something new, we
have to have something interesting and innovative.

People think, OK, should we just do more upgrades or try to sell more
new product? We decided that users like us to do a level of systems
integration so they don't have to get involved in that. So take
Sharepoint Team Services, which we put in Office. We could have sold
Team Services as a separate product, and we could have introduced a new
SKU [stock keeping unit]. We could have decided if it should work down
level with the old Office or just the new version of Office, and we
could do that with real-time communications. But we tend to like to put
things together, integrate them, and then release batches?1202?-- which
are then 'upgrades' -- as a form of introducing our new innovation. But
no matter how you do it, because our stuff does not wear out, we have to
convince people that some idea we have is better or more powerful than
the older idea we had.

And there are two aspects of doing that. One aspect is, on a given
product or upgrade release, does that make sense? Or do we convince you
that over an nyear period of time we will have enough innovation that
you will want to be licensed for that innovation. And this is part of
this whole licensing discussion we are having.

We moved to the new licensing for two reasons, I would say. No. 1, we
wanted to simplify our licensing. When we look back a year from now, I
guarantee you that where we are now is simpler than where we
were. Nothing is simpler during a transition because they are learning
the new and are more familiar with the old, but I think people will
eventually realize this is simpler. Our licensing got pretty complicated
over the years, and some people came to not understand it all.

The other issue is [the timing of delivering] our innovation. I don't
want to have a lot of rough questions [from customers]. So when we do
have new ideas, it's like, OK, should we put it in this upgrade or that
one or just have a stream of stuff that only our best customers have
access to under the terms of their contract? I think in the long run we
have a better chance of satisfying them with the latter than with
hitting them with six different upgrades. I am a fan of [letting] the
customer decide, OK, I want that piece or this piece. But they are
licensed for all of it. So those are the two things we sought to do.

> That gets back to the trust issue, where if you front-load it, that's
> the big, lumpy upgrade; and if you back-load it with the vision, the
> .Net 2003 servers, you have a long gap in the middle where you have to
> sell into an untrusting audience.

The truth is, we need to be better at both. There are some things you
can only do big and lumpy, like a new file system. It's not like some