The Customer-Driven Culture: A Microsoft Story

Chapter 1. Building a Foundation for Change

Throughout this book, we focus on six “culture hacks.” These are lessons we’ve learned on our journey of cultural transformation. These lessons, more than any others, have been the most profound and have given us deep insight into what’s required to change the culture of an organization.

However, before we move on to those specific hacks, we must understand that they are effective only if you have a strong foundation in place. Culture change is like starting a fire, and, like a fire, the foundation is critically important. For example, I could teach you how to make a fire by striking a piece of flint with a piece of steel, but that would do you little good if all you had were a bunch of wet branches.

In this chapter, we explore the core foundational pieces that should be in every organizational culture. These are fundamental truths that show up time and again in every cultural transformation that I’ve personally witnessed or read about.

About the Developer Division at Microsoft

The Developer Division (DevDiv) is a division of nearly two thousand employees within Microsoft. It’s where Monty and I work. We build developer tools for millions of customers that are, in turn, using those tools to build applications and services for their customers. It’s a software development environment that takes advantage of the talents of engineers, program managers, designers, user experience (UX) researchers, documentation writers, business administrators, and many others. The story of our customer-driven cultural journey began in 2013, when we needed to produce software more quickly to meet the demands of an ever-evolving customer base. What became evident very early on was that we not only needed to respond more quickly, but we needed better ways to reduce the distance between the people making our products and the customers who relied on them.

DevDiv’s primary product, Visual Studio, had been in market for more than two decades. In technology circles, a product division with that kind of legacy could easily be dismissed as a dinosaur.

Before our transformation, we had roughly 1.5 million monthly active users. That was a number we were proud of, but the overall market of developers we could reach was growing, and new pressures were mounting. Over the years, we were struggling to grow our audience, and new developers were no longer considering Microsoft developer tooling and services. To them, Microsoft represented their “mom and dad’s company,” not the company that spoke to the developers of the future. After many missteps in engaging with the open source developer community, we had found ourselves in a position with little credibility and trust. We were often seen as the “evil corporation” moved by control and greed, picking on the little guy, and squashing the spirit of the developer community. As the open source development movement flourished, we found ourselves outside the conversation, trying to get back in.

However, through our cultural transformation and the release of new tools like Visual Studio Code, we were beginning to see strong engagement with new developers who had previously dismissed our tooling. They were becoming vocal champions of a “new Microsoft.” Not only were we seeing explosive growth for our new products, we were also seeing tremendous growth in our existing products. In short, existing customers weren’t moving from our “old software” to our “new software”; we were attracting new customers to both products. We were experiencing a profound and exciting shift as we were winning over developers on every device, every platform, and every programming language. We were capturing developers’ interest in our tools, even when they were building on our competitors’ platforms.

DevDiv was coming back into the developer community, stronger and more relevant than ever before. We were beginning to earn our customers’ trust back.

As of this writing, we’re now at nearly 14 million monthly active users: 8 million using Visual Studio and 6 million using Visual Studio Code.¹

Additionally, our Net Promoter Score (NPS), one of the many metrics we use to track our customer satisfaction with both products, is above 55. To give you a sense of the magnitude of these scores, based on global NPS standards, a score above 50, for any product, is considered “excellent.”

DevDiv had proven that an old dog could learn new tricks.

The Culture Room

As word of DevDiv’s success spread, Satya Nadella, the CEO of Microsoft, decided to visit DevDiv to see what we were doing and determine whether any of it could be applied to the rest of the company.

Our team had spent months intensely focusing on answering this question. We had culled over our six-year journey, reflected on the prevailing research, and identified patterns to our approach that we believed, when applied consistently, had significantly influenced our culture.

So, we had a lot to share, but we had to convey all of this learning in 20 minutes, which was the time that was given to our team for his overall tour of DevDiv.

We decided that a simple PowerPoint presentation wasn’t going to do the trick. For him to truly understand what was happening in DevDiv, he needed to see it for himself.

We landed on the idea of a culture room.

Effectively, we covered every square inch of one of our UX Lab’s rooms with materials that represented the culture of DevDiv, as illustrated in Figure 1-1. There were testimonials; a 10-foot-wide banner of our Hypothesis Progression Framework (HPF); books that had inspired our approach; pictures of program managers and engineers interviewing customers; and a TV running video on loop of our “Developer Day” event, an annual event during which nearly 200 of our employees interview 100 of our customers in a matter of hours. The room also prominently featured the six culture hacks that represent the rest of this book.

Figure 1-1. One wall of our culture room

With it all assembled together, our boring, white, antiseptic lab had been transformed into an incredible exhibit that showcased the very best of DevDiv’s customer-driven culture.

Before we share more about Satya’s visit, let’s look at the foundational pieces that were already in place when we began our journey.

These are important learnings for us, and they’ve become the essential bedrock for our cultural change. Before you can apply the strategies detailed in this book, you must build a solid foundation for change to occur.

The Foundations of Transformation

In Microsoft speak, we have the notion of “Priority Zero” (or as the cool kids say, “Pry-Zero”). I had never heard this term before, but when I first joined the company, it seemed like everyone was saying it. Finally, too afraid to look stupid, I pulled a colleague aside and asked, “What is this thing I’m always hearing about? This Pry-Zero?”

“Oh,” she replied with a smile on her face, “that means, like, ‘before we work on anything else.’ It’s priority zero!” Her eyes became large and she opened her arms wide to indicate that priority zero items had magnitude and importance.

“Well, why don’t we just say it’s the number one priority?”

“Well, because…we just don’t. It’s, like, even more important than the number one thing.”

What I eventually came to learn was that labeling an action item Priority Zero became incredibly useful. Sometimes, you need to consider a foundation of understanding before you begin to add your piece to it. There are times when you must get the foundation set before you start on change. If you went to the doctor because you were desperately sick with the flu, you wouldn’t appreciate it if he chose that opportunity to start a conversation about a low-fat diet. That’s just not the right foundation to start that conversation.

As I stood there in our culture room waiting for Satya to arrive, I reflected on my own personal experience at the company. I thought about the foundation that had already been put in place in DevDiv (and the greater Microsoft) that created the bedrock for us to begin our transformation toward a customer-driven company. To understand the lessons learned from our journey, what would someone need to know first?

Thankfully for our team we were building on the shoulders of the great work of many before us. Leaders and individual contributors—throughout Microsoft and DevDiv—had worked hard to start the conversation for a new Microsoft to emerge. The following elements in this chapter represent Priority Zero. They represent the foundation you must pursue in order to have a healthy transformation of any organizational culture.

What Is a Customer-Driven Culture?

In The Customer-Driven Playbook, a book I wrote with my colleague, Jessica Rich, we described a process for performing lightweight experiments to better understand your customers and how to apply those insights to build better products. The book was written to help “de-risk” your assumptions and ensure that the products you build are useful and valuable to your customers.

Throughout this book, you’ll see that being customer driven is synonymous with being learning driven. It’s an ethos that states that the best way to serve your customers is to adopt a learning mindset.

In DevDiv, we earnestly capture our assumptions about our customers and formulate them into hypotheses that can be tested. We then run a wide array of experiments throughout the entire development process to ensure that we’re validating or invalidating those hypotheses. What we’ve found is that when you constantly test your assumptions against real customers, you’re increasing your confidence in your product decisions along the way. This prevents us from wasting valuable resources working on vanity projects or “solutions in search of a problem.” In DevDiv, your feature, product, or service will not be shipped unless there is a legitimate customer need.

This requires our product teams to constantly engage with customers. We have state-of-the-art telemetry systems that help us determine user behavior in the usage of our products, but our teams still spend countless hours talking directly with our customers. This rapid learning cadence has been instrumental in our transition toward a customer-driven culture in which decisions aren’t made by ego or politics, but what we’ve learned from the people who depend on our products.

Live Share: An Example of the Customer-Driven Approach

An example of our customer-driven process at work is how we went about developing a feature called Live Share. Live Share enables real-time collaboration for developers when they’re working together, but in separate physical locations. You might be familiar with a similar feature in Office or Google Docs that helps you collaborate with another user over the internet. If you’ve ever used one of these products in this way, you might have noticed your peer’s cursor moving along with yours as you both edit a document. It’s a fantastic way to collaborate with someone remotely, in real time.

Live Share works like that, allowing developers to follow along with one another while they code together on the same application or source code. They can also enter a debugging state in which they can work together, each from their own computer, to identify the point at which an application is failing. The value of Live Share is that, whether you’re reviewing code with a colleague, working with a team during a hackathon, or teaching a classroom of students how to code, it has truly shifted how people collaborate when writing code—especially when they’re distributed around the world.

However, when our product team began work on this project, it wasn’t planning on building anything remotely close to Live Share.

The team began their work by investigating how developer teams engaged in rapid-release cadences. Together with our research team, our product managers were talking to customers who were building apps that required them to push out frequent updates and releases. As we had shifted to releasing updates to Visual Studio and Visual Studio Code much faster than ever before, we were becoming familiar with this landscape of software development. However, we needed to understand their problems so that we could determine whether we could offer them tools or services that empowered them to achieve more.

One of the unique challenges in working for DevDiv is that we’re a division that is full of product teams that are building software for product teams that build software. It can be very “meta,” and if we’re not careful, it can be so easy to fall into a pattern of building tools and features that we want and falling into the false belief that our customers want those things, too. Many of our customers don’t work on engineering teams that are as massive as Microsoft, so if we don’t stay connected to where our customers are today, we run the risk of introducing features and complexity that are unnecessary or cumbersome. Additionally, for our customers that have similar needs to our own developer teams, they can compel us to push our products to new heights and sophistication. It’s a tricky line we must navigate; to constantly push our products toward new futures, but not alienate the millions of customers that depend on our products to be reliable and familiar.

Thankfully, the Live Share team had been following a customer-driven approach. Over the course of a couple of weeks, the team interviewed 25 customers and had rich, vivid conversations with them. They learned about their work environments, how they were writing software as a team, and how they were using not only our tools, but our competitors', as well.

During those early interviews, customers were continually expressing frustration with basic collaboration. For example, when a developer asked a coworker for help on their code, the coworker was spending a significant amount of time trying to find the spot in code the developer was talking about, or, if the coworker tried to look over the developer’s shoulder, they’d have to orient them to their developer environment. Things like the font used or the color theme applied to the editor could create a cognitive burden for the coworker who was trying to help.

It’s like driving someone else’s car: when you first get in, you need to adjust the seat, steering wheel, and mirrors to effectively drive the vehicle.

These situations would happen numerous times a day: getting up to speed with the configuration of their coworker’s tools, identifying the problem and fixing it, and then having to go back and reorient themselves to their own tools and the problem they were working on. This constant back-and-forth was creating countless hours of wasted productivity throughout their week.

The entire product team was involved in exploring the many ways that we could address this problem for our customers. Product managers, designers, researchers, and engineers employed quick, low-fidelity mockups to express ideas and explore alternatives. During their brainstorms, they would diverge, creating multiple concepts, and then converge to narrow their ideas down based on stakeholder and customer feedback. Eventually, they came up with five significantly different ways to approach the problem of peer collaboration while writing code.

With those concepts in hand, the team reengaged our customers, walking them through the concepts and collecting their reactions and willingness to use them in their everyday workflows. At this point, no code had been written on our side, so the team hadn’t become overly invested in any one of the concepts. This sort of “co-creation” embodies the growth mindset that we embrace in our culture in DevDiv and throughout Microsoft.

The team was skeptical about the Live Share concept at first, but the overwhelmingly positive feedback it received from customers when showing them the concept was undeniable. The fact that the team explored multiple concepts and that Live Share continued to resonate the most with customers gave our leadership team greater confidence that we had landed on a great solution.

The work didn’t end after the concept had been validated as valuable—it had just begun. We had raised our confidence on the right thing to build, but the team needed to ensure that it built it the best way.

As the teams brought the concept of Live Share to reality, it fell into a weekly cadence, shaping each detail of the concept, testing various workflows with real customers, and then going back to make refinements. The concept evolved from basic, nonfunctional prototypes, to high-fidelity mockups, to working prototypes, and eventually to shippable code.

Building software this way honors the reality that without customer data and feedback guiding us, we cannot ensure that we’re delivering on customers’ unmet needs. It’s a culture that requires us to check our own egos and be open and receptive to other points of view.

In my journey as a customer advocate, I’ve had many people point to Henry Ford’s infamous, if apocryphal, words: “If I had asked people what they wanted, they would’ve said faster horses.” Essentially, the thinking is, “We can’t trust our customers to give us the information we need to deliver innovative products, because they don’t know what they want. Therefore, it’s up to us to figure it out for them.”

As I just mentioned, it’s under debate whether Ford actually said these words, but he certainly embodied this self-assured mindset.² Henry Ford’s most notable innovations came from the fact that he was a ruthless optimizer, focusing on cost and price reduction. He invented cost saving and efficiently scaled mass-production schemes that are still in use today.

However, Ford wasn’t known for being sensitive to customer needs and requests. A lesser-known quote that is also attributed to him is when he said, “A customer can have a car painted any color that he wants, so long as it is black,” which perfectly captures Ford’s thoughts on customer development and gives us insight into his hubris.

Compare this way of thinking to companies like General Motors (GM), a direct competitor of Ford. Its approach to manufacturing cars was to target specific customer segments. GM focused on understanding customers’ unmet needs and landing on innovations like closed-bodied vehicles and new ways to purchase and finance a vehicle. GM released various innovations that were readily adopted by customers, allowing GM to gain ground on Ford and establish themselves as a worthy competitor.

By 1927, Ford was selling only a third of the cars made in the US. It eventually capitulated and started offering similar innovations that competitors had already been offering for years, and Henry Ford spent a lot of money retrofitting his factories and businesses to do it. Ford had lost its lead because of a false certainty that it knew what customers wanted better than they did.

So, what can we learn from the contrasts between a customer-driven mindset and a mindset that is driven by our own egos, and how can we apply that to building a product culture that focuses on its customers?

The Three Vital Behaviors of Culture Change

I love sharing stories like how our product team built Live Share by putting the customer into the center of its process. When I share stories like this, I’m inevitably asked a question like, “So, what do I have to do to get my product team to operate in this way?” In a sense, what people are looking for is a prescriptive set of steps—a one-size-fits-all solution.

I’m afraid that simply doesn’t exist.

However, throughout our study of culture change, both inside and outside of Microsoft, we’ve identified three vital behaviors that are present when change occurs, at the individual, team, and organizational levels. These three behaviors are: awareness, curiosity, and courage, as depicted in Figure 1-2.³

As we talk about shifting your culture, we will continually point to these three actions as the core behaviors needed to succeed in any change effort.

Figure 1-2. The three vital behaviors of any change effort

Awareness, curiosity, and courage can be applied to any type of change effort, whether it be on an organization, team, or individual level. Let’s examine how they can be applied to building a customer-driven culture:

Awareness

Remaining competitive and striving for first-mover advantage can cause us to rely too heavily on shortcuts in our learning. We often do this by introducing our assumptions into our products and services. Most of the time, we do this unconsciously. Awareness is a vital behavior because we must constantly identify our assumptions so that we can formulate them into hypotheses to be tested. Only then can we move forward with any semblance of confidence that we’re heading in the right direction for our customers.

Curiosity

To build products that your customers love, you must have a genuine curiosity about who your customers are. You need a desire to learn everything about them, from what motivates them, to why they behave the way they do, and what problems are preventing them from achieving their goals. Great product makers have a voracious appetite for learning, and they’re constantly devising ways to learn from their customers. They make decisions by incorporating market reports, customer interviews, in-product analytics, usability studies, and any other customer data they can get their hands on.

Courage

When engaging in a rapid, constant learning environment, there’s a good chance that you’re going to be proven wrong. There will be times when you will be so sure that customers want your idea that it can be extremely unnerving to learn that they don’t. Rather than becoming unmoored, you should be energized by learning a new way your idea won’t work. Being customer driven means having the courage to pivot when customer data doesn’t support your ideas or decisions.

We consider these behaviors vital because all three must be present for change to work.

For example, if you are aware that you’re making product decisions based on your “gut” assumptions, but you’re not curious enough to find a better way, you’re not demonstrating the curiosity that’s required for meaningful change to occur.

If you’re demonstrating curiosity by investing in infrastructure to conduct lightweight experiments within your product but ignoring the data because it conflicts with the business model you’ve already invested in, you’re not demonstrating the courage that’s required to change your business as a result of what you’ve learned.

Hacking Your Culture

Culture is a product and in many ways, it functions like a software product.

Software is a set of instructions that detail how a computer should function given every possible situation. It takes inputs and responds with the appropriate outputs. Software also manages your computer’s resources to make sure that it can deliver performance when given highly critical tasks. If software fails, your computer crashes.

The same is true with organizational culture. Over time, corporate policy and cultural norms shape the instruction set. A newcomer to the organization must “download” the culture to understand how to operate efficiently and successfully within it. And just like software, when a culture crashes, it threatens to bring the entire organization down with it.

So, if it’s the case that culture is a product, we could certainly shape it by using the same customer-driven processes the product team used in making Live Share. In this case, our fellow employees are our customers. We can listen to them, collect their feedback, and adjust to meet their unmet needs. We can institute small-batch changes, test their effectiveness, and roll out larger changes when we have greater confidence in the outcome.

Just like a software product, we can “hack” our culture. Not in the “infiltrate the system and steal the valuable data” sense of the term; rather, in the hacker spirit of incremental experimentation, tweaking, debugging, and fixing. In the context of positive culture change, we mean hacking for good.

In keeping with this theme, the six chapters that follow represent hacks that you can apply to your change management process to make progress on your cultural growth. Our culture hacks are as follows:

1. Establish a Common Language

2. Build Bridges, Not Walls

3. Encourage Learning Versus Knowing

4. Build Leaders that Build Your Culture

5. Meet Teams Where They Are

6. Make Data Relatable

Through our experience working with countless teams and in different industries, we’ve found that these hacks create a culture that will help teams focus on their customers, unlock innovative experiences, collaborate respectfully, and engage their work with a sense of urgency and purpose.

When you consider hacking your culture, you’re really ascribing to a mindset that is like the Lean engineering practices used in software making today. Lean espouses the virtues of moving quickly, adjusting as you gain new information, and continually pursuing new information in a close and collaborative way. You must apply this same Lean process to your cultural development, keeping what works and discarding what doesn’t. Approach building your culture with humility and a desire to continually learn how to shape the path for your employees to grow.

Just like with product making, with culture building, you’re never done. As your customers’ needs and desires change the landscape of your product offerings, the needs of your employees will change the landscape of your culture.

Pursuing Purpose

Earlier, I mentioned how one of the first things Satya did in his first year was to update our core mission statement.

His goal was to illustrate where we should find our sense of purpose and our ambitions. To him, we would find those things if we were willing to recapture what had made Microsoft successful all these years. He referred to this as our “unique core.”

In his email to employees, Satya laid out his view of the path forward:

In order to accelerate our innovation, we must rediscover our soul—our unique core. We must all understand and embrace what only Microsoft can contribute to the world and how we can once again change the world. I consider the job before us to be bolder and more ambitious than anything we’ve ever done. Microsoft is the productivity and platform company for the mobile-first, cloud-first world. We will reinvent productivity to empower every person and every organization on the planet to achieve more.⁴

What was so salient to me that day was that he was calling for us to stop focusing on what Microsoft needed to do to win and put our focus on what truly mattered: helping our customers win. To do this, we would need to be aware of our own deficiencies, be curious and willing to learn new ways to help our customers be successful, and have the courage to put our customers’ needs before our own.

What was so great about this call to action was that it was exactly the right focus for the company—at a time when the company needed it most. This email had been sent immediately on the heels of a major release of Windows 8. The reception to this latest version, a radical departure from previous versions of Windows, was lukewarm…to put it generously. The company had made a bet that tablet computing would be the path forward for our customers. Therefore, the product teams building Windows completely reimagined the operating system to focus on touch functionality.

Touch computing on traditional laptops didn’t materialize as a strong consumer demand like we had hoped, and many customers were annoyed that they had to pay a premium for touch-enabled computers.⁵ Combine that with removing the iconic Start button from Windows 8, and critics were knocking the company for being out of touch with customer needs.

Additionally, it was becoming abundantly clear that Microsoft was not making progress in mobile devices. Google’s Android and Apple’s iOS mobile operating systems were absolutely dominating the mobile phone space while Microsoft’s Windows Phone operating system languished.

In fact, a year after his shift in the company’s focus, Nadella would make another dramatic decision by writing off $7.6 billion in assets to move away from the acquisition of Nokia that had happened prior to his tenure.⁶

With devices like the iPhone capturing consumers’ attention, Microsoft had begun to obsess over the competition, pushing ourselves into spaces where we were not uniquely positioned to provide value. In our desire to be more like Google, Apple, and Amazon, we had lost sight of what made us uniquely Microsoft. Our focus had become fixated on what our competitors were doing and not on what our customers needed.

Many in the industry thought that Microsoft’s worst days were ahead.

Nadella disagreed. To him, Microsoft had simply lost its way. Employees just needed to be reminded of our central purpose: to empower others to achieve more. That was the spirit upon which Microsoft was founded. That’s what we were uniquely positioned to do, and in his mission statement to all the employees at Microsoft, that was what Satya was asking us to reclaim.

To build the culture you desire, it must center on a unifying mission that everyone can drive. The goal must inspire action, and it must be audacious.

Notice how Nadella asked us to empower every person and organization on the planet to achieve more. I like to think our leaders intentionally chose the word “planet” just to ensure that it covered every square inch of our world. We weren’t going to just focus on business customers, governments, educators, healthcare providers, consumers, students, or small business owners. We were going to look for new ways to ensure that everyone could do their best work.

In his famous “moon speech” on September 12, 1962, President John F. Kennedy didn’t stand at the podium of Rice University in Houston to ask the country to “consider going to the moon at some point.” Instead, he inspired the country into action by reclaiming the nation’s spirit and its desire to see the very best of what America could do.

In his book Built to Last: Successful Habits of Visionary Companies (HarperCollins), Jim Collins refers to these types of goals as Big Hairy Audacious Goals (BHAGs); they’re clear and compelling and serve as a unifying focal point of effort. Collins writes, “A BHAG engages people—it reaches out and grabs them in the gut. It is tangible, energizing, highly focused. People get it right away; it takes little or no explanation.”⁷

Having a core mission isn’t just a rallying cry that inspires the troops. Research suggests that compelling goals have a tremendous impact on behavior, causing the blood in our bodies to pump more rapidly, our brains to fire, and our muscles to engage.⁸ Compelling goals literally put our bodies into action.

In our Customer-Driven Workshops in DevDiv, we ensure that each team receives a relevant business goal for its area to work on during the week. For example, a team working on Visual Studio might be assigned a goal like, “Triple the number of Python developers using Visual Studio as their primary editor over the next six months.” Trust me, this is audacious. We don’t have workshop attendees work on superfluous goals that are meaningless. We don’t say, “Okay. For the next four days, each team will design a better bike helmet.” Sure, if our group was responsible for helping Microsoft make better bike helmets, this could be a great goal, but we work on tools for developers.

Because our workshop attendees are given an audacious business goal for which they are directly responsible, we achieve much more engagement and commitment in our workshops. Our workshops aren’t seen as “required training”; rather, they’re an opportunity to generate real career capital and solve real problems.

Younger employees—for some of whom Microsoft is their first job out of college—really latch on to these challenges. Millennials, the generation of employees born between 1980 and 2005, have become the nation’s largest workforce. Numerous surveys of these 82 million young workers have suggested that they place far greater emphasis on purpose, passion, and meaning in their work.⁹ Although a competitive salary is still important, millennials will also leave jobs where they are unable to connect their own purpose with the organization’s greater mission.

The point here is that, to galvanize a group of people and drive a culture change, you must rally them around a core goal that is immediately accessible and audacious enough to push them farther than they ever thought possible.

Kathleen Hogan, Microsoft’s executive vice president of human resources, says that purpose is what helps her lead, even in challenging times.

“Sometimes, leadership is hard,” she says. “But having that sense that what you are doing is something you deeply care about, that’s what I lean on when I have days when I think ‘we are not delivering.’ Coming back to that purpose and why this work matters, that is key to propelling you forward in your journey as a leader.”¹⁰

Diversity and Inclusion

To build a culture that serves the ever-changing and diverse needs of your customers, your organization must reflect the same level of diversity in its workforce. You simply cannot discuss building a strong culture without addressing the need for diverse backgrounds, perspectives, and voices.

Numerous studies show that diverse teams perform better,¹¹ are more creative,¹² and make more ethical decisions.¹³

So why then do organizations struggle with creating a diverse workforce?

Microsoft has certainly had its own missteps as it tries to create a more diverse company. In 2019, an internal email thread leaked to the press, detailing numerous stories of harassment and inappropriate behavior that women at Microsoft were experiencing.¹⁴ The stories were horrifying, and it was clear that our plan to be a diverse and inclusive technology company was not working. Many employees were outraged and demanded that Satya and other leaders at the company address the claims of discrimination and harassment much more quickly. Urgent action was needed.

For me, watching our leaders respond to these issues has been painful, but also inspiring and informative. It was incredibly difficult to hear those stories, and it was hard not to be disappointed. However, by listening to these employees and leaning in, I was able to confront my own unconscious biases as well as own that my positive experience at Microsoft hasn’t been shared by everyone, particularly those in underrepresented groups like women and people of color. It was an important learning and I’m grateful for it.

Despite our best intentions, it’s human nature to seek homogeneity and harmony within our workgroups. We seek confirmation of our beliefs and often gravitate to those with similar backgrounds, experiences, and thinking. We like people who have the same sense of humor as us, like the same things we like, and have similar opinions to our own.

The challenge is that these implicit biases could be excluding voices and experiences that are different from our own for the sake of expediency or to avoid conflict. Therefore, we must remain aware of and act against those biases to prevent them from weaving their way into our day-to-day working interactions.

Amanda Silver, partner director of program management in DevDiv, says that diversity and inclusion is about the three aforementioned vital behaviors: awareness, curiosity, and courage.¹⁵

Silver says that these behaviors show up in the context of everyday situations. One example she describes is a meeting in which you have half the team members physically present and the other half dialing in remotely over the phone.

“[In these situations], what is the order of operations that you must have to ensure that every voice is heard and that there’s not a power dynamic?” Silver asks, pointing to the clear advantage team members have when they’re physically present in meetings. They can read body language and interject much more easily than those dialing in over the phone.

“Everyone can relate to this. This isn’t just about gender, ethnicity, or class,” she says. “Some people are physically present, and some people are remote, and you have to make accommodations to ensure that remote people are included in the conversation.”

To Amanda, these situations require awareness that there are people in the meeting who cannot be seen.

She says it also requires curiosity: you need to check in with remote members to ensure that they’re not having a difficult time interjecting into the conversation.

“So, what you do,” she continues, “is you naturally build in pauses into the conversation and you do checkpoints, where you ask questions [of remote members]. You intentionally call on the people that have been silent to make sure they have an opportunity for their voice to be heard. [As a leader], your job is to make the room for everyone else on your team,” she says.

Amanda uses the remote meeting as just one minor but meaningful example of how she shows up as a leader. She exhibits the three vital behaviors, not just for remote employees, but she also points to how they can be helpful in accommodating other differences. For example, she says that people who are generally more introverted also need more time to process and reply, just like remote employees. They’re easily overlooked if she’s unwilling to check in with them and ask them questions.

What makes Amanda an exceptional leader is that she models a learning culture by applying awareness and curiosity to her leadership style, continually looking for ways to better engage her team and uncover the best ideas.

Finally, she says that behaving in this way requires courage.

“It takes courage to let someone else speak,” she admits, “because you might be creating an environment where their contributions are valued—and potentially valued even more than yours.”

“For people who have only seen it done one way,” she continues, “where the loudest voice in the room wins, essentially, and the way you absorb power is by being loud and taking up space. If your goal is to have a learn-it-all culture, you actually can’t take [all the] space. Your job [is] to make room for everyone else on your team; and that takes an incredible amount of courage.”

Fight and Unite

The key to bringing diverse voices together is to be willing to have the debate and then seek to unify the group with a common goal built on mutual respect and understanding. Management professor and author Morten Hansen writes that teams are best when they “fight and unite.”¹⁶ To do this, you must make it safe for others to challenge ideas or assert their point of view. It’s impossible to create a free exchange of ideas if people feel intimidated to speak up or challenge conventional wisdom. Rigorous debate can be uncomfortable, but it’s necessary. Where debates break down is when they turn toxic or personal. That’s why finding unity is so crucial. A team must have the debate, give equal time for everyone to express their view, and, most important, all agree to commit to supporting the outcome.

At Amazon, one of its core cultural principles is to “disagree and commit.” Low-level employees are encouraged to make major contributions, and having a high status at the company doesn’t prevent you from receiving criticism on your ideas.¹⁷ After a decision is made at Amazon, employees are expected to dedicate themselves fully to it. Essentially, there’s a time for a debate and a time for action. That’s a “fight and unite” mentality.

By actively asking quieter employees for their opinions or including people with different job functions or life experiences, you’ll create an atmosphere in which people feel respected and included. They’ll also be much more likely to buy into the culture you’re trying to build and unify with others behind your efforts. You’ll build advocates, not quiet dissenters. Most important, your culture will reflect the experience and wisdom of many, not just a few.

These behaviors might take more time and patience, but the outcomes are worth it. Culture cannot be mandated. It must be something that you grow together.

Zero Distance

Let me close this chapter by returning to our visit with Satya Nadella.

When he came to visit us in DevDiv, I was beside myself with excitement and nervousness. When he entered our culture room, my pulse began racing, and my brain was screaming, “There he is! There he is! There he is!”

Followed by a small entourage, he walked up to each of us, shook our hand, and offered a warm smile. His kind demeanor and gentle nature put all of us at ease.

Monty walked him through the six culture hacks we had applied that influenced and scaled customer obsession in DevDiv (i.e., the next six chapters of this book).

Jessica showed him the HPF and talked about how our teams use the process to engage customers and collect feedback. It was fascinating to see how quickly he understood it and began to apply it. At times, he became animated, walking from one side of the poster to the other to explore new ways that we could utilize the framework.

I had the opportunity to discuss our workshops, and Satya asked if he could attend, but his assistant was quick to remind him that he didn’t have four days available in his schedule. He seemed a bit disappointed with his congested calendar, and I found it amusing that, even as a busy CEO, a chance to learn a new set of skills was still an exciting opportunity for him.

Kelly Krout, a principal UX research manager on our team, then walked with Satya to the center of our lab. From that vantage point, he could see the handful of separate rooms where we were conducting studies with real customers. Our team was on one side of a two-way mirror, with our customers sitting on the other side.

At one point he asked, “Can I go into one of these?” pointing to one of the rooms that was conducting a study with two developers using Visual Studio.

Kelly looked at him a bit incredulously. I’m sure he was thinking, “You’re the CEO, you can go anywhere you want!”

From behind the glass, he stood with the product team and watched our customers use Visual Studio in real time. His smile was wide as he leaned in to get a closer look. After acknowledging several of the product team members conducting the study, he asked Kelly, “So is everyone here a researcher?”

Kelly replied, “No,” and started pointing to each person in the room: “In this study, we have a program manager, an engineer, a technical writer, and a designer.” He then pointed to Karl Melder, a researcher on our team who was standing in the back corner of the tiny lab room. “That’s Karl. He’s our researcher; he’s organized the study. The team benefits by interacting with the customer directly, so he likes to get out of the way, this way they have a direct connection with the customer. In this case, our program manager is asking the questions during this interview.”

Like many large companies, Microsoft has also struggled with its top-down structure and strict adherence to job titles and descriptions. It’s not uncommon to see fiefdoms sprout where practitioners safeguard their functions to protect their jobs.

What Satya saw in our lab, was that Karl was glad to take a backseat and have a program manager play the role of researcher. Our goal in DevDiv is to put zero distance between product teams and our customers. That’s what we obsess over. In this example, Karl was following through on Satya’s mission by helping his colleagues achieve more.

This was Satya’s vision for the company culture, a highly collaborative group who invested in each other to best learn from and serve the customer.

In his book Hit Refresh, Satya reflected on his visit to DevDiv:

It is refreshing to see how they have rewired their own product creation process to be more focused on customers—exploring hypotheses and then validating or disproving them through testing and engagement with people who buy and use our technologies and services. The logic was to change their language to open themselves to possibilities.¹⁸

Without Satya’s clear mission and the tireless work of so many others to reform the attitudes and behaviors of people at the company, DevDiv’s transformation wouldn’t have been possible.

The foundation had been put in place; the Priority Zero cultural elements were being addressed. The rest was up to us, just as it’s now up to you.

With that in mind, let’s dig into our first culture hack.

¹ [Greenwood]

² [Vlaskovits]

³ Credit goes to Sheila Anderson and Joshua Tabak, two superbly talented and resourceful program managers at Microsoft. They discovered these vital behaviors by examining patterns between our customer-driven work and our diversity and inclusion work. With their help, we were able to illustrate how awareness, curiosity, and courage, apply not only to how we should work with our customers, but to how we should work with one another as well.

⁴ [Nadella] pp. 78–79

⁵ [Ranger]

⁶ [Warren]

⁷ [Collins] p. 94

⁸ [Influencer] p. 18

⁹ [Field]

¹⁰ [Bulgarella]

¹¹ [Richard]

¹² [McLeod]

¹³ [DeGrassi]

¹⁴ [Tiku]

¹⁵ [Silver-1]

¹⁶ [Hansen] pp. 140–165

¹⁷ [Sunstein]

¹⁸ [Nadella] p. 245