I appreciate Microsoft so much, and I hold the company in very high regard. The experiences I have had here I couldn't have had anywhere. After almost 10 years, I will change industries and roles, and relocate my family to a new region. I am very excited for the opportunity to help customers through pharmacotherapy.

I will miss my team, I'll miss getting ready for patch Tuesday, I will miss the pleasure that is working with the Office team... and still (by a long way) the best productivity suite in the history of software.

Best wishes and may our paths cross again...

Update: Details about the release and its contents have been published to the Office Updates blog.

September caused us to spend time examining some of the processes we're using for updates. We have made adjustments to our pre-release procedures for testing, release preparation and communication.

For me, this is the first release in my 3 years of leading this team that was intensely personal. The outreach from customers and the engagement I've had with Susan Bradley and others pertaining to September has been very educational, and has put an exclamation point on something that everyone on my team understands: Our customers are very passionate, they want and need our support. I am thankful that we have dedicated IT professionals who are as open and willing to provide us the feedback we need to get better.

If our language in prior communications was not clear, please allow me to say this: We apologize for the issues caused by our September update. We strive to provide an outstanding customer experience, and we fell short of that commitment in September.

The challenges we faced in September were internal timing issues. Late changes caused us to do things at the last minute in an attempt to ensure our release was of the best quality possible. Unfortunately our changes resulted in a situation that was worse than the one we fixed. Zeroing in a bit further, the issues were not that things were "late," it was that the final release version of the shipping packages arrived in a staggered fashion. That they landed at different times in the ship cycle created difficulty in a number of operational contexts. We are pretty familiar with late-breaking changes, but in some cases, even the 190 years of combined release experience on my team can't overcome some of the challenges introduced by late stage churn. Adjusting for this we have implemented (re-established) a normal timing and cadence for updates. Between development, build, test, packaging, we're focused on reducing the variability within the system, giving every internal team a greater opportunity to evaluate release candidates in total.

Another area where we received feedback was our communication pattern for changes to our update releases. We use a combination of KB Article updates, Social Media, our Support forums and our Support teams to get the word out when we need to alert folks of issues. The synchronicity of those updates was a little weird in September, mostly due to the need to find the first available channel to communicate. Some latency is natural when we are moving quickly to remedy a problem. Moving forward, however, we will have a much more coordinated approach for communications. Our blog posts and social media updates (what we are able to do most easily) will reflect what our support teams are saying, what our forums entries communicate, etc. Additionally we are working with our Customer Support teams on better early warning guidance and other areas that will improve the customer experience in situations where issues are evident in our update releases.

I'm at the edge of diving into the "Inside Baseball" talk that only makes sense to those who know exactly how we do this work so I'll leave it at that for now. But the effect should be clear in the future, and I look forward to your feedback on our changes in these areas.

We are looking at additional investments to make MSI patching for enterprise updates easier. Stay tuned for more news in this area.

What we also learned in this release is the efficiency of Office 2013 Click to Run SKUs, specifically Office 365 and other retail versions of our 2013 release. Because these are whole image updates and stream to the desktop clients automatically, the challenges manifesting for MSI customers did not impact Click to Run. Something we've always known internally, but is now more evident externally is the efficiency of Click to Run updates and the relative ease of staying in sync with changes we publish to our products. If you're not evaluating Click 2 Run versions of our software for deployment, it is probably time to start. This is a very good update experience, we are investing heavily in making it better.

As always I welcome your feedback. I'm not perfect, but I will do my best to ensure you are satisfied with our products. Feel free to reach out to me through the blog or otherwise.

A term recognized across the IT industry is "Patch Tuesday."

I'm hopeful this post will remind folks about Patch Tuesday stuff they already know, and hopefully to ring the bell of "common sense." Unfortunately Patch Tuesday isn't universally known, and most people aren't aware of the background or rationale for our approach. It is my ongoing hope that people reading this content are either learning new things, benefitting from having the basics explained to them, or surrendering myths or misperceptions about our update businesses. In any case the history of Patch Tuesday is interesting, and explaining our approach may help. In summary, the question asked and answered is "how do you update hundreds of millions of endpoints every 30 days without creating massive disruption?" The answer: "Very carefully."

Vague metaphor: Some people see streaks of light. Others see two boats passing each other at night in a busy harbor reading each other's navigation lights and following some basic conventions.

Patch Tuesday History

Patch Tuesday emerged as part of a broader security initiative undertaken by the company in 2002-2003 as a result of an increase in the number of threats to the Windows environment. Where Microsoft had previously shipped updates on a weekly schedule, it was decided that a monthly schedule combined with advance notice for time to prepare would be a more tenable customer experience for installing updates. At that time all products moved to the Patch Tuesday schedule.

Concurrently, the Windows Update, Microsoft Update and Office Update methods were evolving. Originally released for Windows 95 as a web site, Windows Update allowed users to manually visit a web page, connect and download updates via the web. Eventually the concepts of critical updates and notifications were added to Windows 98 products, giving way to Automatic Updates added for Windows ME and beyond.

In 2005, Microsoft announced a change to Windows Update, introducing the transition to Microsoft Update, to include updates for other products. This began the deprecation and eventual demise of Office Update, leaving Microsoft Update as the primary channel for updating Microsoft Office.

Fast forward 8 years, where today we have hundreds of millions of regularly updating clients, and billions of downloads each year. SAP, Adobe and other software companies have adopted a similar update method, and Patch Tuesday is almost taken for granted. Patch Tuesday has been proven as an effective method of keeping desktops up to date. We have invested quite a bit in update management, beginning with technologies designed to facilitate easy updating, as well as policies and communication guidelines to make the updates more understandable.

Office and Patch Tuesday

Microsoft Update delivers updates to hundreds of millions of users, scaling to large installation numbers very quickly after publishing. The scale and speed of distribution of these updates necessitates a level of caution when deciding what to ship and when. If even a small %age of customers are affected, that can quickly scale to millions or tens of millions of people. We watch the uptake of an installation with a microscope. We carefully monitor installation successes, failures, their causes and we try to learn as much as we can about the environments in which they manifest.

The combination of what ships when can be a tricky area. Our goal is to go as fast as possible. When vulnerabilities or critical updates span platforms or products, however, an alignment of schedules an priorities is necessary to ensure we don't unnecessarily expose one product for the sake of patching another. In some core components, we must sim-ship our updates. For example our Mac products, IE, Office and SQL might need to ship an update on the same day. Keeping 4 or 5 major product lines on cadence with update releases can be daunting, given the multitude of branch, build, automation, development environments in use.

For Public Updates / Patch Tuesday updates, we typically offer only those updates that are most critical to our global customer base. When everyone is affected by an issue, such as a security vulnerability, we offer that update globally. Through the history of Office Updates, you can review the list of what we've shipped, and quickly determine that little falls outside the domain of critical or security. The "Critical" vs. "Important" designation is a criteria of MSRC documented on the Security TechCenter.

In other words, if we take the risk to offer it to everybody, it is an update which we feel strongly that should be applied as early as possible.

How Office365 and Services are Changing Public Updates and Patch Tuesday

An interesting area where we're seeing some change relate to who Office365 and other services that have heavy interaction with Office client applications. Services evolve, as data is understood from their usage, we learn more about how to better optimize client interactions with the services. For example, we encountered a handful of scenarios where sync to online folders wasn't always working as expected, or performed poorly in certain configurations. This update was a change we made for the benefit of service customers, and for the benefit of SharePoint customers syncing document libraries.

In many ways, this is "just another update," but in many ways it is a signal of the future of updating Office. We learned about these issues partly from customer reports or external reports, but performance and other aspects of service interaction are things we learn from telemetry. We are investing heavily to ensure that we are aware of any potential trouble before our customers are aware. And when we are discovering those things, we'll use the Public Update channel to distribute those updates. As our services grow, we want to ensure Office has a successful interaction and users are satisfied with the experience.

This is a departure (an addition) to our traditional response-oriented critical update strategy, and it is part of how Office begins to look more and more like a service. We are supplementing our common escalation channels (the usual mix of Microsoft Support, Communities, MSRC, Dr. Watson, etc.) with more direct line of sight into service health and customer experience. This addition of new sources of telemetry and incident information will increase our speed of issue resolution. The more we listen, the more we learn.

Before we get into the considerations of release cadence and Service Compatibility, it is probably good to start at the beginning. I find these posts are always useful as a digest to initiate the new users, and to refresh those who haven't visited this subject in a while. A myth defrag is usually in order. In this post, I'll break down some of the fundamentals of our update strategy, including what we ship, where, to whom. Beyond explaining the basics, I'll get into some of the lesser known aspects of updating the clients. All of what I am describing applies equally to our MSI-based installations as well as Click 2 Run. We'll get into the practical differences between MSI and C2R in a future post.

Gratuitous image as a vague temporal marker.

Our Support Policy

Office client updates are distributed on a regular basis to improve the quality of our products. Updates generally fall into a basic category: Security, Customer-requested hotfix, or just a plan "change." In the past, virtually all fixes for Office in-market products were a direct result of customer escalations. That is less true today with the increase of telemetry sources, our alignment to Office 365 and other factors. Over time we have moved from more of the cause / effect or direct engagement model to one where we are better at anticipating customer challenges and resolving them before they become actual problems. The most obvious example is our work with security agencies to address vulnerabilities before they become public, or looking at installation failure rates for a given update before their broad-scale release.

The most important factor in determining which products we update and with what changes is best outlined in the Microsoft Product Support Lifecycle. You can read the details beneath the link, but generally:

Our current releases of Office benefit from a 10-year product lifecycle. In other words, we will be publishing updates for our existing releases until 10 years after their initial availability. The dates for Office product support can be found here. As you will see from the site, Office 2000 and Office XP are no longer supported. We are no longer issuing updates for those products. Office 2003 is set to expire next year, along with Windows XP. You will also observe that Office 2013 is supported until October of 2023.

The first 5 years of product release are for hotfix release, service packs and security / critical changes. In this initial 60-month period, we respond to Microsoft Premier Customer requests for hotfixes, we respond to other requests, for example, from our consumer support teams or from other product groups seeking changes to improve compatibility across our product lines. We call this phase "Mainstream Support."

In mainstream support, we have historically offered 3 service packs during the 60-month mainstream support window. Service Packs are important milestones in deployment - they are a roll-up of all fixes to date, and they reset the support baseline for a given release. For example, the recently released Office 2010 Service Pack 2 is the current baseline for the 2010 release. Per the terms of the Office Service Pack Support Lifecycle, the prior baseline will expire from support 12 months from this release date, giving customers a full year to deploy the release.

The second 5-year period of support is termed "Extended Support" and we offer only security, critical and compatibility changes for products that are in this phase. Office 2003 and Office 2007 are both in their extended support phase, and if you take a look at Microsoft Update for Office 2003, for example, you'd see that the only available updates are marked as either security or critical.

Our Release Cadence is Designed to be Predictable and Transparent

Public Updates ship on "Patch Tuesday," or the 2nd Tuesday of each month. They contain Security Updates, Critical Updates and Global Updates. These are provided to everyone and designed to be installed by every user. These are offered to users via Microsoft Update, and WSUS Catalogs, and as Click 2 Run images.

Cumulative Updates ship on the 2nd Tuesday of even numbered months. (Feb, April, June, Aug, Oct, Dec). These are generally unadvertised, because they are releases of hotfixes requested by our Microsoft Premier customers. These are delivered to the hotfix server, and require an email address to download. For Click 2 Run customers, an image containing these updates is available, but the changes are not automatically downloaded until the next public update. More on how PU and CU relate to each other later.

Service Packs ship on the 4th Tuesday of the month. We tend to ship them once per 18 months, although there is no pre-determined schedule for those releases. The purpose of a Service Pack is to reset the support baseline, so that we can keep customers current and offer them the best support possible. Service Packs are published to Microsoft Update, the Download Center and in WSUS Catalogs.

Determining the Contents of a Release

The contents of a release can be determined by an examination of the associated KB Articles, which detail the affected packages or changes we're delivering. We keep a handy blog here, and we maintain an Update Center on TechNet, which has a handy feed to which you may subscribe. We also publish content to known channels like the Security Bulletin center on TechNet and other places.

Office Updates are Always Cumulative

This aspect of our strategy is not well understood, but has been true for a long time. All Office updates are cumulative. Every change or update installation contains all changes to date for that component. For example, a Security Update for Word contains all changes to date for Word, which includes all prior security fixes, hotfixes, bug fixes and other changes. What we don't do is create separate versions for specific updates or release channels - there isn't a "Public Update only" version of Word or a "Hotfix only" version. All changes are cumulative.

For Click 2 Run, this makes things very simple. Each time a new image is delivered to you, you have all changes to Office that have been released. Because those images currently ship on Patch Tuesday, you are getting the most current version of Office on a 30-day cadence.

For MSI installations, the problem is somewhat more nuanced, but the end effect is the same. If you install all MSI packages, you will be current on all changes for those packages. For example the Outlook.MSP package delivered in a PU release will contain all changes to date for the files in that package. By design, these packages interoperate with the existing support baseline, corresponding to a released service pack level. In other words, Office 2010 changes apply to the new SP2 baseline, and they will apply to the SP1 baseline for one year after the release of SP2. After this 12-month period expires, those updates will no longer target the SP1 baseline.

This detail is destructive to the myth we frequently encounter related to Service Pack testing. Because Service Packs are roll-ups of existing fixes plus some additional change, customers current on Public Updates have already installed the bulk of changes in a given Service Pack. The binary versions are sometimes updated and there are incremental changes, but these are generally of the variety of changes that don't meet the bar for a customer release - e.g., too small. I covered this a while back in a blog post on my team's site.

#1 FAQ - What's the Best Way to Stay Current?

I'm asked this question a lot. The answer is pretty simple -- Use Automatic Updates.

If you are a Click 2 Run customer (e.g. you are a user of the Office365 product, or you bought Office 2013 in a retail outlet) keep updates turned on. The image updates on Patch Tuesday will be streamed to you when they are available. This is a very low-maintenance approach to getting current.

To enable automatic updates for Click 2 Run products like Office365 or Office retail products, visit the "Account" Tab under the file menu.

For MSI customers, use Microsoft Update to take automatic updates. You won't update as much as we change in any given Click 2 Run update, but you will accumulate all changes to relevant parts of Office over time.

For managed deployments, I'd encourage you to examine your desktop updates policy closely, to determine whether it is appropriate to take updates through Microsoft Updates. In most cases it is perfectly appropriate (better), and in those cases C2R versions of Office are worth considering because they make the update process so much easier. We will continue to invest heavily in C2R technology moving forward.

Of course all the fine-grained control of MSI installations remains available. This is appropriate in many environments, and we will continue to support this customer need.

In my next post I'll dive into some of the practical differences between MSI and Click 2 Run technologies, and explain the implications for managing desktops.

Since I joined our release management team 3 years ago, we have been operating with a mantra that our updates will improve the quality of the product over time. We continuously strive to make the product more stable, more secure, more performant.

At this moment the software updates business is at a crossroads. Patch Tuesday is well known at this point. Alternative updating strategies are becoming more mainstream. The most striking examples are the rapidity of single or few-instance services which are continually updating and refining in response to feedback and incidents within the service. Game client applications backed by online services require updates to log into the server and play. Stores filled with mini "Apps" are usually a complete re-installation when "updates" are published.

This mode of hyper-currency has great benefit to provider and to consumer. In many cases the rapid update cadence is paired with an aggressive, Agile development methodology which forbids / reduces bug backlog. Thus the time from discovery to resolution can be very short if the backlog is of a manageable size. Fixing bugs delights customers. Doing it faster is a good thing for everyone, so long as the experience doesn't get in the way.

Except...

In the case of a product like Microsoft Office, updating our products is a carefully managed exercise. Perhaps we are unique or on a very short list of peers in this regard, we have hundreds of millions of endpoints, all at various patching levels, with an infinite number of hardware and software permutations. Unlike gaming clients or single-instance services, Office client applications are usually connected to line-of-business or 3rd party add-ins. Within businesses this is more often the case than it is the exception.

Combining the diversity of the ecosystem with the complexity of the environments in which Office does its best work raises interesting questions in figuring the best approach to the new world of software updates.

Recently Jeff Teper was describing our intent to accelerate the cadence with which we deliver updates. As part of the Office 365 offering, we must consider how we are going to approach this problem for all of the connected client endpoints participating in the service.

I am going to treat this post as an ongoing dialog on our approach. This post will grow over time - stay with it and watch it unfold.

When it is complete, I hope to have a full description of the factors we're looking at for a faster release cadence, the approaches we're going to enable, considerations our customers might weigh, and hopefully collect some feedback along the way.

Feel free to participate in the discussion.

 [View:https://www.youtube.com/watch?v=u6XAPnuFjJc]

At Microsoft we have a competency called “Cross-group Collaboration” which is used to illustrate the degree to which one is successful in employing tactics like “managing without authority,” “holding others accountable,” “creating win-win situations” and all that. Even in writing that sentence I cannot help but surface some of the cynicism I have for those concepts.

The adult definitions are strikingly similar to the concepts we’re taught in pre-school:

This isn’t to say that I think we manage people like 3-year-olds. What I am saying that many of the competencies used in assessing our performance at work are basic life lessons in a specific context.

These principles are defined in so many places by so many people that their application takes on an artificial quality that separates the behavior from the intent. In the worst examples, these cross-group collaboration competencies are forged into instruments of career torture. Events in one’s day to day life evolve into context-free samples of how one is failing the basic rules of “don’t hit,” “be nice,” and “share your toys.”

Desire for excellent collaboration among individuals at work is not the problem. Defining attributes of successful workgroup collaboration isn’t the problem either; <recruiting commercial> Microsoft does well in defining what this looks like in our company. Microsoft spends a lot of time on Career development for employees. The model we use for career development (and the tools available for employees to use in doing it) is something you have to see to understand. If it is not unique in the industry, I’m certain that few companies can come close to matching what we use here. </recruiting commercial>

The problem arises when the definitions for Cross-group collaboration become untethered from the purpose of doing it well. This post is about the purpose of cross-group collaboration.

What is the root of collaboration in the corporate environment?

(I’m sharing my own thoughts here, but here are some obligatory resources: https://www.creativityatwork.com/CWStore/OCAWe-book.htm, https://www.ami-communities.eu/wiki/Collaboration%40Work, https://tucsoncitizen.com/wise-work/)

My mental model for the problem is as follows:

If Microsoft was a company of one, this would all be so easy. I would go ask a bunch of people what they wanted in a software package, write some code to meet their requirements, test it myself, ask them to help me test it, figure out how to package and price it, spend some time on the road selling it, and eventually get back on the treadmill and do it all over again.

Because I would always have all the data all the time, and my ability to relate business functions is dependent only on my memory, I would have little need for anything beyond a day planner and a notebook to record notes for future reference.

Because I have two young children at home, I am unable to sustain this life. I need help. Much like cell division, I need to produce more people to do the work. For each cell division capacity is increased by 2 and/or workload is halved. The largest tradeoff I consider in adding people is the degree to which work is divided into autonomous functions vs. roles where information must be shared between the parties. Where I now depend on the second person for information, I create a potential communication problem.

Unfortunately humans aren’t perfect communicators, and adding people introduces inefficiency that accumulates with each cell division. Capacity falls somewhat short of doubling with each cell division, and workload absorbs that impact. Each cell division might separate half of the existing work, but the burden that collaboration places on people adds new work. I could introduce some cute mathematics and limit equations here to illustrate the example, but the concept is simple and doesn’t require that.

At some point after a large number of cell divisions, 1,2,4,16,256, the burden of collaboration on each cell’s workload, combined with the cumulative productivity loss across all these functions requires some solution. Welcome our new “management” team; people who are put in place to reduce the efficiency drain and to reduce the net workload effect collaboration places on individual cells. They do by organizing, filtering and sharing the relevant details across different functions in the organization. This solution is a shortcut, because we’re taking a bet that we can’t make people perfect communicators, we have practical needs which force us to do something.

For those who have a pessimistic view of the role of management, take note. I’ve encountered many folks who view the role of managers as reducing vibration within a system. I see it differently. The essential role of management is to reduce the efficiency drag and workload burden inherent in organizations where the role scope is narrow and dependent on the output of others. (The role of ‘leadership’ is different, and perhaps the subject of a future post.)

This is also why “the smartest person in the room” is often the last person you’d want managing a team. People who don’t feel like they should depend on others generally won’t. They make poor facilitators of collaboration. Subject matter expertise can aid one’s ability to communicate and to close gaps, but toy sharing and subject matter expertise are different skill sets. Effective managers are ones who can facilitate productive interactions. Subject matter IQ helps, but if nobody likes working with you it won’t matter. This reminds me of an old saying, “If you want to go fast, go alone. If you want to go far, take a group.” I don’t know who said it, but it makes sense.

We are not a company of one. I believe we have more than 75k employees (estimating conservatively because I’m too lazy to look up the actual number). At a company of this size, there are many, many layers of management. We use complex systems to facilitate information sharing and the collaboration that is required to keep so many cells functioning as a unit. It is imperfect.

For all the models, systems, SharePoint, and other things we use, nothing is more important than the ability of people to connect with each other. This is why we care so much, and this is why it looms large in performance discussions. We value the ability to collaborate and to work well within our organization, regardless of how the imperative is encoded. Whether you learn it in Kindergarten or on the job, cooperation matters because it reduces drag.

Employees and managers are cogs in a functioning system; they are not independent agents acting in each other’s (presumed) best interest. Collaborating well in the corporate environment comes down to your ability to identify mutual goals, move quickly through the ‘who does what’ parts, and to use that framework to measure and communicate progress. And it requires you to be nice to your neighbor. For all the explanation, the strategy is basic and easy to employ.

Sadly, another lesson I had to learn the hard way.

• BPOS Customers can now view service status through a new dashboard. An RSS feed is also available.
• Mac Office will Arrive on October 26^th. Office 2011 is a fine product.
• We changed some of the licensing terms for Business Contact Manager (BCM). Justin’s post summarizes the changes pretty well. This is a welcome change and is good for Office customers.
• Trouble with Office? Start here. This page has a ton of resources to get you going in the right direction. Lots of useful links here, including a path to downloads for Outlook Social Connector, Ebay plugin for Excel, and a few others.
• In case you wanted to see what 4.4 speed looks like. I’m only sad that you had to be there in person to understand what 123 decibels sounds like.
• As for the CodePlex/Outercurve foundation, well, timing is everything. But this is interesting news and I wish for their continued success.

Taking a left turn for a moment on the software talk.

I’m at a point where I have to vent on a topic, and no better place to do it than to the anonymous reader. For some reason I’ve been in a lot of these lately (usually the presenter or I am needed for some reason; not as the presentee), and I’m at a point where I just have to empty the chamber on the reviews that are failing for lack of experience / guidance on how to do them well.

With this and so many other things in my management career, I am compelled to teach people to avoid the same mistakes that I make / made. With my enthusiasm for developing people is combined a new perspective of "the other side of the table." I understand now what I could not understand before.

I used to be so bad at this. (Maybe I am still not very good at it.) At some point by design or by intervention, a meeting shows up on the calendar titled "business review" or something similar. These are the dreaded "tell me what you think is important enough for me to know" type meetings, they are common in large companies, where high-level managers don’t have great visibility into the daily lives of people in their organizations. I’m in my 11th year of practice, it took me quite a few to figure this stuff out.

I thought I would share my thoughts on what makes a good review. Having seen enough of them go the wrong way, and being on a streak of reviews that have been moderately successful, I can summarize what I believe the formula to be.