046. Prioritizing a New Type of Customer [Ch. VIII]

This new chapter begins the middle of the PC era, starting in 1998, as I experienced. In a very short time, the industry from customers to suppliers, went through enormous change. It is easy to look at the products to see the change as we moved from 8-bit or 16-bit systems that could hardly power the software we wrote (that practically did not work) to 32-bit processors with 32-bit operating systems. Or to consider the change from character mode to graphical and to client server mode (both the fragile model as implemented across all the major platforms, and the loosely coupled model as the WWW embraced). Equally important, and perhaps even more so when it comes to how Microsoft evolved, is the transition from selling products where the buyer and user were the same person, a tech enthusiast, to selling products to an entire IT profession. The next three chapters detail that unprecedented transition and how it dramatically changed Microsoft. As we will see here, it was not just the products or customers, but the very nature of how the company was managed.

Back to 045. Incompatible Files, Slipping, Office 97 RTM

Since the organization was still in the early stages of creating Office first, rather than apps first, there was pressure and challenges that came from the race to start planning the next release. Apps figured if their plans could be put in place then they would be harder to unwind in favor of other ideas from the Office Product Unit. And so, the planning for the next product release began in an uneven manner prior to RTM for Office 97.

But over the next three product releases, almost seven years, the Office team and the business transformed. The era of apps, each operating independently, gave way to a coherent Office suite. The single user of productivity tools on a personal computer was the toehold upon which Microsoft built an organizational productivity toolset that became an integral part of IT infrastructure in large organizations (LORG). The focus on LORGs and the transformation of the business to multiyear enterprise agreements (EA) resulted in an increase in revenue, profits, and ubiquity of Office and set the stage for the business for years to come.

Although Office was sold as a bundle, it was built as independent, and award-winning, products. The next step was to build the product we were selling, an integrated productivity software suite.

The journey, however, was difficult and repeatedly pitted our efforts to build innovative and empowering software for individuals against the demands by IT professionals to reduce change and maintain a level of control over the ever-sprawling, always-connected personal computer.

These changes in the business and role of Office required the team to transform from a set of reasonably well-executing but independent entities, OPU and the app product units, to a single, execution engine. We needed LORG product development machinery to match the LORG business that was growing. Building software, at the time, was still too hit or miss, quality too uneven, and predictability lacking. These were all qualities that our new, and extremely large, customers were demanding of Microsoft. If we were to sit across the table from General Motors, the Department of Defense, or Proctor & Gamble we needed to operate at scale as effectively and maturely as they operated their organizations, even if we were making relatively newfangled PC software.

PaulMa was leading Platforms and had recently returned from one of his many trips visiting with CIOs and enterprise customers. PaulMa, more than any other product leader, was responsible for Microsoft embracing the dialog with CIOs most of whom were not from the PC generation, but began their careers on mainframes. Paul pushed across teams to engage with CIOs and even upgraded the Microsoft Executive Briefing Center against BillG’s wishes to provide a very deluxe setting for CIOs (and government leaders) from around the world to visit Microsoft and learn the latest in technology from the newly crowned leader. Upon returning from this trip, Paul wrote up his notes as he always did and proclaimed that he heard very little about “open systems” (as Unix was called). In fact, customer dialog had dramatically shifted away from open and towards “making Windows work”.

The root of the problem was a phrase total cost of ownership or TCO coined by the industry analyst firm Gartner Group. TCO measured the real cost of computers and servers in organizations, not just the cost of hardware and software licenses, but all the internal costs for training, management, upkeep, helpdesk, upgrades, and more. The numbers were astounding when we saw them. One of the first TCO reports from Gartner concluded that a Windows 95 PC connected to a network in a business costs almost $10,000 dollars per year.

Strategically, the Network Computer, NC, was a huge topic of discussion. The NC was a form of PC championed by Oracle and Sun that only ran a browser. That seemed crazy to us at the time. To the benefit of the PC, Gartner did not find these to be radically cheaper in terms of TCO. That did not slow down the conversation at all.

Paul immediately declared a war on TCO. As we’d come to expect from the Platforms culture, this was the new crisis. Suddenly there were meetings, offsites, slide decks (lots), and more. Platforms seemed to always love a good crisis. The thing was this was a real crisis.

Office 97 was very exciting for end-users, but between broken file formats, tons of new features requiring training, and especially because of the addition of email, we found ourselves essentially the enemy of IT professionals. Windows 95, so loved by consumers, was proving exceedingly fragile in an enterprise environment. There was great hope for NT 5 (no codename, which I totally loved), if only there was an Office to go with it. NT 5, however, lacked the consumer features of Windows 95 (and the follow-ons Windows 98, Windows 98 SE, and then Windows Me).  In other words, we had a product crisis on our hands due to TCO.

The people buying our product were IT professionals with an entirely different lens on product needs and capabilities. The buyer and the user were no longer the same person. Importantly, almost no one building products on the Office team had even the slightest experience working in an IT controlled environment.

Across the company this challenge could be looked at as a call for Microsoft to “grow up”, probably for the third time. Jon Shirley (JonS) joined Microsoft in 1983 after 25 years at Radio Shack, a great Microsoft customer. He came as the company was growing rapidly to bring a classic model of experience in scaling a small company. MikeMap and PaulMa brought a product development maturity five or so years later.

Now Microsoft was at a scale where no single person could up-level the company. Instead, we began an era of formal management and training as a way of instilling at least some common set or baseline experiences. These “HR courses” (Human Resources), as we called them, would become both objects of ridicule (I mean who doesn’t make fun of HR courses) and also brought a lingo and way of talking about Microsoft that we could at least share across the three different cultures in the headquarters product groups (Apps, Platforms, Online).

We experienced enough challenges building Office 97 in how different parts of the team worked together or even communicated with each other. Across the company these difficulties were compounded to the point that cross-company work was often hit or miss, as I personally experienced going as far back as building tools for NT 3.1. By the late 1990s, it had become all but impossible for people to even move across cultures and when they did often successful people would experience a form of organ rejection. As an example, one of the strongest leaders in Apps was asked to move to NT to bring a bit of apps program management to the team. He ventured over to NT and lasted only months before he roundtripped back to Apps, both sides convinced it was a horrible idea. Multiply this by dozens of people, the need to collaborate on code, and now the customer demand for products to work together in new ways and this was a huge problem.

Leading this charge for HR was NatalieY. Natalie who was the cultural beacon of the company and had recruited me to work for BillG was determined to help Microsoft mature. She hired many people who developed a broad curriculum and took so much grief for the work they did, though ultimately it was Natalie who convinced a skeptical BillG, SteveB, PaulMa, and many others to endorse, participate, and encourage the formal training.

This was not without a few early disasters, at least a disaster as far as a group of us were concerned.

Forming, Storming, Norming, Performing

When it came to these HR classes, I reacted as anything but supportive and open to them (as was the case for most engineering brains). I always felt I had my fair share of touchy-feely training as a resident advisor in college, where I underwent countless hours of introspection and sharing.

In fairness, however, I learned vocabulary that proved useful over the next years as a manager and leader. Like almost any of these extracurricular experiences (they were never required), what tended to make them most valuable was not necessarily the content but the timing of the content relative to what was going on.

One straightforward class was on organizations and teams. Its singular takeaway was the framework for how teams evolved. Tuckman’s Stages of Group Development was from the mid-1960s, but outside of an HR class there was no chance I would have been exposed to this. The timing of the class was perfect.

As the research described, a team goes through phases of forming, storming, norming, and performing. With this framework we discussed examples from our jobs. It was simple and non-controversial. It helped me to put the conversations JonDe and I had with ChrisP and PeteH in context—that idea that the Office team had lost its marbles.

The OPU and Apps teams were all in different stages of team formation, and at the same time individual perception of where the team was might not have coincided with an objective measure. While Excel as a team might have thought it was performing, that was only the case so long as building Excel was the goal (Excel was clearly our highest performing team at the time). The Office team finally shipped features in Office 97, but to say it was beyond the early days of norming was an exaggeration.

I walked away from the class believing all of DAD (which we continued to call Office, though that name would not be our official division name for a couple of years), OPU and the Apps, were organizationally much earlier than the business results would have us believe. In many ways, we were still storming. Looking at the reviews of the product and where customers were, we could also say that Office suites were slightly ahead and customers were beginning to see suites as normal, especially customers that adopted Windows. The class was a wake-up call to not assume anything about how the team operated as we developed the organization and plans for what would come next.

Each one of the spinning plates of Office maintained a process for ideation, planning, and execution, but we needed a process to bring these together and to scale from teams of dozens to a single team of hundreds. There was no playbook, and we knew that at this point while other parts of Microsoft were having their share of (enormous) success, there were no repeatable processes to emulate.

We needed to invent a new Office process while also building a new Office.

Another HR class became an accidental legend and provided endless entertainment and stories after the fact. A selection of about two dozen people from the product groups, including JonDe, ChrisP, me, and many across major divisions, were invited with few details to a training offsite. NatalieY picked a selection of cool kids or influencers as we would say today, assuming we would endorse the experience and more would choose to participate.  

We were sent reservations for travel with no lodging, just a flight. We flew to Boston (mysterious) and then took a small plane (like Wings) to Cape Cod.

There was a lot of eyerolling.

Upon arrival in the tiny airport, our luggage, wallets, ID, laptops, and new Motorola StarTac and Nokia 6110 phones were confiscated. We learned that before our arrival, leadership for the United States Postal Service had just experienced the retreat and loved it, which seemed to worry us. We were taken to a primitive location, a sort of religious summer camp where we were divided into three groups. The first were “tops” (I did not make up these names), who received instructions prior to the training, arriving a day earlier (JonDe was a top). The tops were assigned nice rooms. The second were “middles,” who were given group accommodations. The largest group were “bottoms” (of which I was one), and we were given what appeared to be the kids’ bunks with no linens.

Over two days, the middles were given various goals from the tops and some resources to carry them out, such as clearing dirt paths or washing picnic tables. In turn, the bottoms worked to accomplish the goals in exchange for provisions (like sheets or food). Our first assignment, we spent a few hours clearing leaves in exchange for lunch. We were trapped on the Cape without any communication tools at all, not even a payphone.

It was not going well for me—while I spent many summers camping in a tent, it was by choice. Being forced into this, with no idea what was happening, was not cool. I began plotting my own escape but couldn’t even find a phone, plus I had no money though I had my AT&T calling card number memorized if I could just find a pay phone. I was not alone. In fact, one person actually escaped by hiking to a nearby gas station and using a payphone. He caught a flight back, abandoning his luggage and laptop. He wasn’t just complaining like me, he literally escaped the island.  

At one point, I was serving dinner to JonDe, as a way to secure linen for the evening. We were told that the next day we would receive richer tasks and be given more exciting things to do. After sleeping in a bunk bed with a sheet and using a washcloth for a towel, the next morning we were given tools to create an economy, so to speak, and we could do things for money and stop bartering.

It felt absurd. ChrisP, also a bottom, devised a coup in hopes of ending the farce. We took the supplies for the “town” and everyone started creating art—paintings and drawings, and such, and selling them to the tops at inflated prices and then buying each other’s products at even higher prices. In other words, we flooded the economy with money. We ended up with more money than there were provisions to buy, and the game literally collapsed. The organizers were alternating between laughing and crying. Hungry and stinky, I took to yelling at one organizer, who eventually shut down and walked away.

We broke the entire system, cutting the entire simulation short by two days. We thought we were clever. Really, we were kind of a bunch of jerks. Just horrible. When I think of how I behaved at this course, I have nothing but regret. Forget needing to mature for CIOs, as a group we needed to mature as human beings.

Game over.

We learned that the workshop was a famous organizational behavior workshop based on some important academic research. They conducted this exercise (at this same location) hundreds of times before and never anything as crazy had happened. Suffice it to say, there was a sense of old-school Microsoft pride in having hacked and destroyed the entire training exercise.

However, all was not lost. We walked away with a set of important lessons about organizations—though to be fair they could have interoffice mailed us the pamphlet and skipped the trip. The essence of the experience was to better understand the power dynamics across different strata of an organization. We tend to think of tops being in charge, middles balancing the needs of the bottoms and tops, and bottoms as victims. In practice, every individual can take on the behavior traits, beliefs, and coping mechanism of each layer. Every role is a bit of each layer or caught between competing layers.

As crazy as all of this was, the core idea of bottoms as victims, tops as all knowing, and so on being highly context dependent did in fact have an impact on me. Years later, a friend in HR begged me to go to a three-hour version of this workshop held at Microsoft. For years I forbade anyone on the team from participating in this class out of retaliation for my suffering. I conceded and found the short version to be quite beneficial, and I recommended it for many.

In reflecting in several email threads, the most important lesson for me was that while a group of us really hated the training, there were people that did not mind it and some even liked it. In fact, some of the people from Platforms wanted to have a follow-up. Perhaps that spoke of the diverse cultures more than anything.

Still, the legend of breaking Power Lab is one for corporate history.

Note. The internet is filled with experiences teams and companies have had with Power Lab. A search yields many extremely positive discussions, and not a single description of breaking the simulation entirely. In 2005, I wrote of my experience for a MSDN blog. I detailed the lessons more specifically. The post is available via archive.org.

On to 047. Don’t Ship the Org Chart

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit hardcoresoftware.learningbyshipping.com