Remarks by Ray Ozzie, Chief Software Architect, Microsoft Corporation
Microsoft 2008 Most Valuable Professional Global Summit
April 17, 2008
RAY OZZIE: Thank you. Thanks a lot. Thanks. Great to be here. This is my first MVP Summit. This is very exciting for me. You guys are a very special crowd. I hope that you've had a really terrific week. I love the format of this, you know, a lot of chances for close interaction with the product teams. I hope you've made some friends. I hope you've met some more people on the product teams that you haven't in the past.
More importantly, selfishly from my standpoint, I hope the product teams have met you. I hope they know your faces. Sometimes knowing a face behind an e-mail address is really a healthy thing; it gives more of a feeling of accountability to the outside, and that's another reason why I love this.
I've been very fortunate that over the course of my career, which is about 30 years, I've had the opportunity to work for a number of companies, very small, couple of startups in Iris and Groove -- (cheers) -- hey -- a few medium-sized companies, Lotus, Data General; and then at the high end, you know, IBM and now Microsoft.
One of the things that's been really clear to me over the course of all of these different projects and teams that I've been exposed to is that there are different challenges that teams have with different types of projects in terms of how to get feedback into the system, into the design process, into the development process.
With small products, with low volume products and early stage products it actually tends to be pretty easy to get feedback. You bring something new to market, some early stage people self-select and they jump on this thing, and you know who to listen to. You call them up on the phone, you e-mail them, you get to know them, you fly out and see them, and each iteration of the product that you do is really for those early people. Especially if you have a platform product, something with APIs, you need very, very early on to find out who is going to be your key application so that you can set up kind of a codependent loop where they depend on you, you depend on them, they're helping you to understand maybe challenges with the semantics or the performance of a certain set of APIs, and they need you to win, you need them to win. It's really, really healthy.
But with high volume products there are a tremendous amount of challenges. And I can tell you, having been on the outside of Microsoft, that we always look at the MVP program with a certain degree of envy, and we really couldn't figure out how to get such a thing bootstrapped.
I remember this very vividly because in I believe it was '93 when the program was starting, I was working on a project that had suddenly become a high volume product, and it really causes the development team to kind of undergo a shock when you're going through that transition.
Initially you get to know all these early stage customers; suddenly you're inundated with feedback. Just you have so much feedback you just don't know who to listen to. Tons of e-mail, people are writing about it.
So, the development team tends to do the most natural thing; it builds a wall around itself. We hire people to kind of act as the buffer. And the development team, left to its own devices, would kind of become a little bit isolated and lose that sense of contact that is so important in terms of developing something that's relevant to the outside.
So, who does the team really listen to, or who should it listen to? Should it listen to the executives who are maybe funding the project? Should the teams go out and listen to their friends and family who might be touching the product and seeing things from a little less biased viewpoint? It's very tempting to read the press and prioritize features and things like that based on what you read. But in doing so, you lack the qualitative feel that you get when you interact with somebody face-to-face, or a lot of times developer needs or IT needs are not really adequately reflected in what's in the press, and if you just paid attention to the press you end up with an overbalance on competitive issues, and you might skip something really important.
With really highly successful products you run into these scale issues, and you really need to find a way to select special participants, people that you really listen to, that reflect just the right set of feedback that helps you use your constrained resources very wisely in order to have the greatest impact moving forward.
You know, if you just take something that I'm sure you're all very, very familiar with, Wikipedia, Wikipedia has 7.5 million contributors. They have lots more users, but there are 7.5 million people who contribute, edit, and create pages. But only 1 percent of those, 7,500, are responsible for 50 percent of the contribution to Wikipedia.
The founders of any given project try to set the direction, but really it's those early participants, those early contributors who are really shaping the nature of what that product is going to be like moving forward.
The quality of the articles, the nature of the articles on Wikipedia are high because those contributors, that 50 percent really is shaping what that technology is really becoming.
Digg -- Digg is a Web site I'm sure all of you are familiar with. The top 100 contributors to Digg contribute 56 percent of the contribution. For those of you who have used it, you've seen the nature of Digg change over time, and it's really because of the nature of what those 56 percent of the contributors want that site to become.
So, who do you listen to if you've got a scale issue like this? You listen to the people who care about what you're building the most, people who have a stake in it, people who have their own conceptual model of what they want it to become.
For Microsoft's products, for our scale products that means you, and you care, clearly care a lot. By the numbers, by the results, it's just incredibly impressive how you've connected with us, how you've chosen to connect with our products and with others in the community.
There are about 100 million participants in online tech communities surrounding our products, but as you well know, there are only 4,000 MVPs. You and others who are not in this room post an average of 10 messages a day to these online tech communities, and that represents about 70 percent of all the postings that are online.
Selfishly, from the perspective of the product groups, MVPs are just so very important. MVPs only represent 1 to 3 percent of the people who are participants in our beta programs for our products, but you report about 20 to 30 percent of the bugs that actually get fixed, which is just staggering. I mean, you are the ones who are -- I mean, thank you. (Applause.) You are ensuring the quality of what happens moving forward. It's your connection with the development team that ensures that we're allocating our scarce resources in different areas in the right way that will have the most impact.
So, thank you for what you do and thank you so much for caring, genuinely. We really couldn't do what we do without you.
You know, over the course of the past two years, as I've progressively assumed the role of CSA from Bill, I've had a chance to meet with many, many product groups across the company. Everybody kind of has their own style. My style is something that -- well, you might refer to it as an outside in kind of style. I'll meet with a product group, and they'll be all excited about a feature that they've put in or a set of features or a set of technologies, a bunch of new APIs that enable some new capabilities, and they want to talk about those technologies. They are technologists, they know I'm a technologist.
But I have kind of a discipline, and at the beginning of meetings I ask them really to tell me a story, to talk about some audience, some member of some relevant audience on the outside that might care about what they're working on.
I asked them to tell me about an individual end user or an IT person or a developer whose product will be impacted, whose job will be impacted, the way that they do things, just tell me one, two, three things that will be meaningful from an outside-in perspective.
And I do this because unlike the industry of old, in the mid '80s when kind of I got into the PC industry, in that era it was so supply constrained that you could pretty much build anything that was really interesting or innovative and new, and there was an audience that was just waiting for it. People wanted to play with new things and give you feedback.
But the environment today is far, far, far different. It is not supply constrained by any stretch of the imagination. We have an abundance of amazing choices of technology out there, products and services for enterprise, for IT pros, for developers, for individual end users, and we have to really deeply earn the attention of each one of those audiences, that you and they have a world of choices.
So, the guidance that I give to teams is that they really need to, from the outset, within the product development process, they have to find a way to build bridges to their audience, they have to really characterize and understand what's going on, on the outside. They can't just use statistical measurement mechanisms of what menu options people use, or look at the bug reports in an automated way, and use that as an influencing mechanism. You have to bring the qualitative aspect of what the audience thinks about what you're doing into the development process.
So, they really need to build bridges that are two ways. In that spirit I really do want to take the time this morning to build bridges to you. I'd like to know what's on your mind, what is it that -- I could stand up here and talk for an hour about any particular product or service or whatever, but I'd like to know what are -- from a priority standpoint how do you write things.
So, Toby, why don't you come on out here, and again while Toby is coming out, I just want to say thank you again, because you are a really, really integral part of our success together, so thanks. (Applause.)
TOBY RICHARDS: All right, so as I mentioned, in true MVP Summit feedback, this is an opportunity to have a conversation with our chief software architect. So, we'll have people who will line up at the microphones. I have talked with a number of people about this opportunity with Ray here, so I did get a couple questions that I'll start off with, and then we'll move to the microphones.
The first is, last month at MIX you attempted to put the software plus services strategy into a big picture context. Could you just replay some of the key themes from that session?
RAY OZZIE: Sure. I'm not sure how many of you had a chance to watch that. It's posted online. I'll kind of give a -- I'll play it back. Since we're talking about internal development teams and how they reach out, I'll kind of use that as a way of framing it.
Really the question, one of the questions I was trying to answer is how do development teams, who have been mostly working on software products for many, many years, how do they characterize the way that they should be transforming their products in a world that is so heavily Internet centric and Web centric these days? Because I believe fundamentally the Internet is a transformative growth opportunity for just about everyone who can embrace it, and it really is how should each one of these products envision it.
I really boiled it down to three principles, and depending on which team I'm talking to, I'll concentrate on one of these principles more than the other.
The first one is that the Web really is a hub, it can be viewed kind of conceptually as a hub of our social mesh and of a device mesh. So, fundamentally one of the things that the Web has brought us is a simple, easy way of bringing people together.
I know it's hard to imagine right now, but it wasn't too many years ago where we didn't even have our LAN e-mail systems within enterprises connected to one another. There was the ARPANET and the Internet have been around for a long time, but it was an academic phenomenon, government and education phenomenon for quite a while. The fact that it's there as a default way to bring people together makes it much easier to build systems that bring together business partners, bring together individuals to work on collaborative projects.
So, just pivoting thinking around the social mesh and how to weave things like shared content spaces, tagging, ranking of content, publish and subscribe of information from public sources, all sorts of new capabilities, and there are a core set of services in the social realm that pretty much every product has the opportunity to integrate that change the nature of the experience.
Also from a device standpoint the Web can be a hub in terms of bringing the number of devices that we have together. We've done a pretty good job as an industry over the years helping enterprises manage tens of thousands of computers within their enterprises, but as individuals we've got more and more devices, we've got phones, we've got multiple PCs, we've got Media Centers, Media Players, phones and so on, and the Web connect is a very convenient hub to bring them together to synchronize information, to synchronize images and things like that.
These two models manifest themselves most clearly in our connected entertainment strategy that brings together devices from the Xbox to the TV or the Zune together for media sharing and gaming, essentially using the Internet as a hub.
Also our connected productivity strategy, we're repivoting our productivity work from being completely PC-centric to thinking what productivity scenarios can we address that use the best of the PC, the rich, interactive editing, the best of the Web in terms of sharing information and publishing to other people, and the best of mobile devices, because everybody has a phone with them at all times, it has capture ability, some phones have styluses and stuff, and you might want to just record something, take a picture, and have it factored in to projects that you're working on, on the PC and the Web.
The second high level principle that I've tried to guide the teams on is with respect to server-service, symmetry, and that is the power of choice within the enterprise of choosing to do on-premises applications and solutions or hosting those things in the cloud. Each and every enterprise has some tempo that they're using to evaluate and try and ultimately deploy some mix of software on-premises and services within their organization.
I believe that we're in a fairly unique position because many enterprises depend upon us, many of you help IT people understand how to manage those systems, and those same learnings can be leveraged if we use those same offerings or variances of those offerings, and bring them to the cloud.
The third principle is really mostly about development. I kind of stole a tagline from David Weinberger from his book, "Small Pieces Loosely Joined," because I think it actually creates the right imagery, and that is that we're moving from a world where we built monolithic software programs, whether it's PC programs, server programs and so on, and we're moving to a world where both at the front-end and at the back-end our software is being fragmented in some meaningful way.
On the front-end we're moving from a world of a single presentation mode for a given application to one where people, customers, individual users are expecting to consume applications on PCs, on the Web, on their phones, as appropriate to their lifestyle, to their mobility, and so on.
On the back-end it's also changing. We would have built scale-up server-based products, but the cloud utility platform world that we're moving into offers a new kind of capability that requires us to rethink our programming models and do horizontal scaling across many, many, many computers, whether for robustness or reliability, scale, and so on.
So, in any case, these three primary principles, one of the Web as a hub, one of the power of choice, and the way that programming is changing to be more or less a fragmented model, are kind of that's how I'd frame it.
TOBY RICHARDS: Thank you.
All right, well, we've got a bunch of people lined up. Why don't we -- wow, it looks like we've got a few Canadian fans over here. So, why don't we go with microphone number one?
QUESTION: Good morning. I'm an MVP for printing and image.
One of my passions, outside of the MVP program, as well as integrating into it, is the environment.
The question I have is being that software is one of the major engines to creating e-trash or e-waste by obsolescing equipment, which has all sorts of toxic materials in it and causes all sorts of geopolitical problems along the way, what is Microsoft doing in terms of its operating systems and other software to try to help lengthen the lifespan of the actual physical equipment? Manufacturers are doing in part their part to try to reduce toxins and reduce the amount of materials they're using. But at the end of the day we all have a basement full of stuff that we don't know what to do with, and Microsoft's operating systems and other software are helping to push those into non-use.
So, I'd like to know if in terms of operating systems there's any thought being given to instead of making the operating system determine what software -- what hardware we need, whether the operating system can be a little more friendly and look at the hardware and say, okay, you can't do this or you can't do that, but you still can do all of this?
RAY OZZIE: It's a good piece of feedback. (Applause.) The industry has grown traditionally by pushing the limits of hardware, of software pushing the limits of hardware, generation after generation.
There is kind of a broad rethinking going on within our industry to begin with, even separate from those concerns, because the clock rate of processors has more or less stabilized, and we are rethinking in terms of how we craft our software in terms of whether it optionally takes advantage of multiple processors, what we do in terms of the usage of the specific resources that are there.
I have to be honest with you that most of the environmental efforts that I've seen in terms of the number of people concentrating on it at Microsoft are really in the realm of power management right now. At both the desktop and at the datacenter level there's a realization that on the desktop many of the technologies that we've used for laptops are equally usable for desktops, and that by throttling down different pieces of the hardware on the desktop, for those people who leave their PCs on a lot, we can do a service to the world and to the environment.
On the datacenter side these are we're at the beginning, at the early stages of having huge, huge datacenters, and the biggest cost in datacenters, there's kind of a conventional wisdom that the biggest cost in datacenters is people and operations people, but, in fact, the biggest cost in datacenters is excess capacity. Most datacenters run at just embarrassing levels, low levels of capacity utilization, and for every idle PC that's sitting in there, you know, it's taking cooling, it's taking all sorts of energy to maintain that thing.
So, one of the things that we're concentrating a lot of effort on, both for our cloud datacenters and for enterprise datacenters, is in terms of mechanisms of using virtualization and just intelligent systems management software to make the best of the hardware, the best use of the hardware that's there, throttling down machines that are not in use, that you need for capacity spikes and so on.
But I hear you; you've got a very, very good point.
QUESTION: Thank you.
TOBY RICHARDS: All right, why don't we go to microphone number two?
QUESTION: Mr. Ozzie, thank you very much.
One of the strategic changes in Microsoft's direction over the last five to 10 years has been moving into the mainstream of business applications. I want to begin by taking -- borrowing one of the sentences you mentioned in your previous speech in which one of the main components in new products is the feedback of those very early adopters.
Number one, why is it so difficult to give feedback to Microsoft business applications like CRM and PerformancePoint? What is going on with those products in which they are missing opportunities to get feedback, not only from the existing users but also from different people and different elements within the industry that realize that they are part of the ecosystem but find no way, no communication channels with those business areas?
RAY OZZIE: So, I'm going to claim that -- I'm going to try to explain that I do not have specific information on where -- on which products that you are clearly passionate about, which ones use which specific feedback mechanisms, and which ones are highly functional, and which ones are dysfunctional. I did get a dose of feedback earlier this morning and yesterday about some -- a couple of specific products where there are some mechanisms that we want to improve.
I talked to Toby probably a little bit more than Toby wants yesterday about this issue that he brought up of forums versus newsgroups, because I have kind of a history in the communications and collaboration software realm, and there is a really interesting balance that you have to find in terms of something that's very, very tuned to the power users in terms of supporting them at the edge and with rich client software, and having centralized repositories and search.
It does take a receptive team on the other end to make a feedback mechanism work, regardless of the tools. I'm going to take this back and if there are other specific -- I mean, I'm just going to say if there are other specific products or areas that you believe our teams could be behaving more openly, if you believe that the tooling could use improvement, just send me an e-mail. It's firstname.lastname@example.org. I'll make sure that people get visibility to it and understand what's going on.
TOBY RICHARDS: And I think it's important to note, too, that our community programs are part of a broader customer and partner advocacy organization, and it is our responsibility -- and on behalf of you, but the millions and millions of users out there - to continue to strengthen our listening capabilities within Microsoft. And so we're very -- you know, there is a team here today that represents each and every one of those business groups, and they've sat in on all your sessions.
And we know those different scenarios. I actually thought, when I was looking at my own measuring stick, I thought our Dynamics line was a little bit better, but now I'll recalibrate that down, and we'll move forward. So, we definitely have that commitment as an organization as well.
All right, so why don't we go to microphone number three?
QUESTION: I have a question about the software as a service space that's currently existing. If we look out at the Web now with all the providers and vendors, we see Open Source playing a very strong role with a large number of vendors, and it's very different from the Microsoft platform what role Open Source plays as opposed to the other platforms. In fact, Java is Open Source now.
So, my question is, with the Microsoft vision, where do you see Open Source playing a part on the Microsoft platform, and what is your position towards it?
RAY OZZIE: Well, my position toward Open Source generally is that it's a part of the environment. It's very useful for developers to be able to get the source code to certain things, to modify them.
Microsoft fundamentally as a whole has changed dramatically as a result of Open Source in terms of as people have been using it more and more, the nature of interoperability between our systems and other systems has increased. And I can tell you from an inside perspective in terms of dealing with individuals inside, when you build a new product, immediately you start thinking of how shall this product expose its APIs, what type of developer is it serving, should there be SOAP or Web Services APIs, because it will be being used in system integration context within an enterprise, are the people who are going to be integrating with it going to be more of the Web community and should they exposed through REST-based technologies, should the results come back in XML or JSON or some other formats based on the type of consumer of the thing.
Open Source is a reality. We have a software business that is based on proprietary software. We tactically or strategically, depending on how you look at it, will take certain aspects of what we do, and we'll Open Source them where we believe there is a real benefit to the community and to the nature of the growth of that technology in Open Sourcing it. The .NET Framework is a good example of it, and we're working with Novell to make model work so that people don't have to make this choice if they do want to do something with a Linux or UNIX back-end, and so that we can share tools and technologies.
But the bottom line is we believe very much in the quality of Microsoft products. We are an IP-based business. But we live in a world together with Open Source, and we have to make it possible for you to build solutions and for customers to build solutions that incorporate aspects of both.
TOBY RICHARDS: All right, how about microphone number four?
QUESTION: Hi. Thank you. I really have a question about a product you actually might know pretty well, and that product is called Groove. Perhaps.
RAY OZZIE: I do know a little bit about that.
QUESTION: Now, there's another product within Microsoft that's been pretty successful in the last year called SharePoint. (Cheers.)
My question is -- yeah, SharePoint. My question is, is Groove the future UI for SharePoint, because that would be just -- when you talk about your software as a service and talk about exposing services in new ways and in new UIs, there's a lot of overlap there? It seems like Groove really ought to be the way to leverage SharePoint on the desktop. (Applause.)
RAY OZZIE: The word that you said, "overlap," I like to think of as complementary. (Laughter.)
You asked if Groove is the future UI of SharePoint. I might ask the same thing, is SharePoint the future UI of Groove.
Groove is really, really specialized and does a really great job in terms of dynamic collaboration between individuals. That is the design center. It just executes that extremely well.
SharePoint is a great thing at the center in terms of a place -- it's kind of the new file system, the new age file system where we had file shares before; now we're posting them and kind of up-leveling the conversation that happens around those things in the repository.
They are very, very complementary, and you will see in 14 and beyond increasing association with the things that you can do in SharePoint, and the things that you can do with Groove and the client, increasing levels of connections, both specific functions of the UI that are designed to work seamlessly with one another, increasingly the semantics underneath being brought together and so on.
So, it's a good observation, and, yes, that is the strategy.
QUESTION: Thank you.
TOBY RICHARDS: I think we do have a few Groove MVPs here. (Cheers, applause.) Yeah, all right, there they go.
All right, oh, Canada on microphone number one.
QUESTION: Over the last couple of release cycles it seems like things are getting more and more coordinated. It's been really great in a sense that Office just works with SharePoint, just works with Windows Server.
But throughout that there's also been a lot of struggles, and I'm sure that SharePoint MVPs would identify that with the last release of SharePoint, where it got a lot of success, but we saw in a lot of ways struggles that looked like the product got pushed out the door a little prematurely.
With this approach towards connected, distributed systems, and with that coming in, the need to be coordinated, and shipping around the same time, how are you guys going to address shipping in a coordinated fashion without prematurely pushing somebody to ship too early and as a result throwing the pressure on the support organizations and the MVPs to make up for that difference?
RAY OZZIE: Yeah, it's a really, really, really tough question. As these systems -- I mean, SharePoint is a fairly complex system. It's got many, many pieces to it. Some pieces are new, some pieces get -- don't actually get fully tested until people are actually using it in solutions on the outside.
I can't give you some amazing panacea, silver bullet kind of answer. I'll just tell you at a high level the processes around SharePoint -- I'm not sure how much you are familiar with Kurt DelBene, but Kurt has -- he runs that organization, and they have spent a tremendous amount of time trying to understand and balance essentially timing the processes and when betas get out to different communities in order to get that feedback in, and not just end user feedback, which I think is one dimension, but to try to get people building solutions and to building new kinds of solutions on it well before it gets out the door, because if nobody deploys until a service pack it does nobody any good.
The other thing that's overlaid on top of that, that I consider as an opportunity -- it's hard for the development teams, but I consider as a tremendous opportunity -- is the fact that many of these technologies, including SharePoint, are forming the basis for service offerings that have a higher tempo of update.
The Office Live product, which is based on SharePoint in its underpinnings, certain aspects of it update monthly, certain aspects of it update quarterly, every six months and so on. So, that gives us another opportunity. By taking some risks and deploying some of that technology early in a service form before it goes out in a product form, we can get a lot more stress testing on it, and developers who would like to work with us in terms of building solutions against the service may ultimately end up getting early exposure to aspects of the features earlier than they might have in a normal three-year or whatever the normal release cycle would be.
TOBY RICHARDS: All right, how about microphone number two?
QUESTION: Hi. [off mike] … embedded Windows, and with a special interest in pervasive computing, especially the pervasive computing that might not be a tightly focused consumer niche, like an Xbox or a set-top box, things like this.
The specific issue is I couldn't say enough good things about the product group. Over the years I've worked with a lot of them; their innovation and their ability to adapt and accept input.
That's not the way I feel about the external Microsoft organization that the typical enterprise, large, medium or small, sees. That organization, the sales organization, the Windows partners organization, is essentially blind to all developments that you have in the pervasive architectures.
The Gartner survey on infrastructure optimization, for example, has nothing in it that is associated with how an enterprise, an organization IT system can use pervasive computing within its automation and so forth to improve their workflow.
So, my question is, do you see over the next year -- and I hope, right -- an effort to expose the fantastic things that your embedded product group is doing to the larger organization in some way at some level to get those technologies out into the market producing good things for all of us?
RAY OZZIE: It's a great question. What you've done is again given me more to think about and work with and to communicate with the product groups on.
I can tell you one thing that I've already observed that might make you feel better. I would say in the past six months there has been a tremendous shift in the internal visibility of the need of I guess I'll say a componentized or scalable Windows that starts with embedded and is repackageable in other forms for a variety of different devices. This is just a natural function of what's going on in the landscape in terms of different types of devices that people want to use, and the real question of should there be -- what OS should be running on different types of devices. The fact that this visibility has increased is getting people involved from both the development side and on the market facing side, and on our partner side, in ways that there's a dialogue happening in ways that I haven't seen before.
So, I am optimistic in terms of what you've said, but this does give me something else I can go back and talk to the teams about.
QUESTION: Because you don't need much. I mean, the products are there now. It's just a matter of telling the world about them.
RAY OZZIE: All right, thank you.
TOBY RICHARDS: All right, how about microphone number three?
QUESTION: Good morning. My passion in the past has always been developers and Visual Studio, but these days I spend a lot more time with CEOs, and I guess my passion is more about solutions that just work, solutions that are easy for the end users to start customizing and just getting up and running.
So, my question, the things I'd like to hear about from you is what are your thoughts about the consistency of the different products? In the old days, we had Office; you got to know Word, you would know Excel. You'd be able to do basic things. If you get an end user now to maybe customize SharePoint to make a few changes to a list, if you get a power user to make a few changes to a CRM entity, if you get a power user to make a few changes to work items in CFS, it's a completely different experience.
I guess I've watched end users customize SalesForce and other products like this. You don't really leverage much that you learn in one product to another product when you're just a power user. You seem to be forced to go to a developer.
It just seems that -- I guess I'd just like to hear your thoughts about the consistency across different products. I know originally many years ago when I knew little about Microsoft I thought it was a big, great organization, and then I came and I realized it was very decentralized, lots of small teams, which has lots of great things about it. But once you become a mainstream product, and once the small team turns into a big successful product, there needs to come a point where maybe you have a consistency team across the products.
RAY OZZIE: It's a great point, and let me just come back to something that I had said kind of in my opening remarks about outside in. When the organization scales, it is difficult. When an organization is small, people talk to one another. There aren't many things to coordinate. And so a lot of that happens more or less naturally. As organizations get big, as the number of products get large, people focus on their accountabilities and their specific -- the success of their specific thing.
One of the reasons that I have kind of picked up this outside-in style in dealing with teams over the years is simply that as systems become more complex, seamlessness and interoperability, whether it's at the programmatic level, the systems management level, or the end user level, becomes as relevant and as important as any given feature in a given product. If people can just simply use things together or manage them as a seamless whole, they will choose, they will stick with those products.
So, when I meet with teams, that is -- by trying to bring them up and hold them accountable to empathy with the user and empathy with people on the outside, a lot of those questions come up, and people are challenged then to ask and answer those questions regarding other products.
Just commenting from an organizational management perspective, I haven't found in the past that it's effective to create an overlay organization that is just worrying about seamlessness. I think it really has to be part of everyone's job in terms of feeling empathy for the user who has to use the multiple products, and then it will get designed in from day one. And my role is to kind of act as an accountability mechanism for making sure that those kinds of things happen across the groups.
TOBY RICHARDS: All right, so we have time for one last question, and you all have an MVP lead who you can ask questions to for Ray, and so we're going to make the commitment to working with Ray's team on that. So, feel free to -- the Canadians, you'll send that note to Sasha. He's taking notes now, so we'll get it there.
Anyway, our last question is going to be microphone number four.
QUESTION: It's noticeable the steady growth of conversations around virtualization within organizations and in the Internet today, more specifically around server and desktop virtualization.
Microsoft is readying up Hyper-V, and a lot of technologies to allow these technologies to actually happen for the large enterprise. It's going into market with partnership with Citrix and other hypervisors.
I guess the question is, what is your true feeling about virtualization in the enterprise on the server and desktop base? Is this just really hype or is this something you guys truly believe is going to happen?
RAY OZZIE: No, it's absolutely fundamental. It is absolutely going to happen.
I would say you have to take desktops separately. The logic behind virtualization on the desktop is completely separate from what it would be on the server, and in some ways it's different within the on-premises world versus the cloud. So, I'll just touch upon those independently.
Before I do that, though, let me just say that from a TS perspective, Terminal Server based deployment will always be more efficient than virtualization. It was a designed-in, multi-tenant model within the OS. So, if there are applications and solutions that fit the TS model, that's just a terrific model to use, and I would encourage organizations to use that model.
Within the enterprise, virtualization, the simplest and most straightforward way is to just make the best use of the datacenter resources that you can from a consolidation perspective. This is we are absolutely taking it seriously.
There are two phases of that consolidation. Phase one is bringing things together, meaning if you have a scale-up cluster or a scale-up, some expensive configuration of hardware, how can you package much usage on that piece of hardware as you can? The other one is then movement of images amongst the different machines within the back-end. You'll see investments progressively from us in both of those realms.
Taken to the extreme within the cloud, virtualization is absolutely critical. Virtualization is key to making the best use and securely isolating properties from multiple customers that might not use even a full inexpensive CPU, and moving them geographically or whatever to provide resilience and robustness. So, it is something that's extremely important.
On the client I'll only say that the uses of it, the way that the Mac uses it to run Windows and stuff, it's clever. Parallels, they're very clever technologies.
The way that you'll see us take advantage of it over time more and more on the client is our mechanisms around ensuring compatibility. App compat is a very, very challenging thing, and you want to continue to make progress with the operating system. We look to it as another tool in the toolbox to try to help in the compat world without -- enabling innovation while still enabling assurance of compatibility.
TOBY RICHARDS: Ray, any final comments, thoughts?
RAY OZZIE: I'm just going to reiterate what I said. I believe that this is -- people might just regard this as an awards program or whatever. From my perspective, it's a fundamental aspect of the design process that we have to have for high scale products.
So, again I hope you feel, I hope we make you feel like you're part of the process. If you don't feel like part of the process, that's a bug on our side, because you are, and we need you to be a part of that process.
So, thank you again for your passion, for your caring about the products, and for helping us to be a successful organization, and I want you to feel part of that success, so thank you.
TOBY RICHARDS: Very reaffirming to this group. (Applause.)
Thank you very much, Ray.