Before we discuss culture and mindset in Dojo, let’s begin with quizzes on culture.

Q1: Which cultural way of working and thinking is key to ensuring that an Agile approach delivers the best value to customers? (Single Choice)

• a. Using Agile Methodology
• b. Employing Design Thinking
• c. Setting OKRs
• d. Having a shared Vision for the organization
• e. Value Stream Analysis

Q2: Which of the following is above all a new way of working and thinking together for colleagues to adopt in the move to Agile ways of working? (Single Choice)

• a) LEAN
• b) SCRUM
• c) Agile
• d) Product Management
• e) DevOps

Q3: Finding the balance between Alignment (governance and “red tape”) and Autonomy (the self-governing team) is crucial for the success of DevOps. Which of the following statements are true? (Multiple Choices)

• a) Too much alignment will lead to less innovation, less motivation, and less collaboration – it can stifle creativity and engagement.
• b) Autonomy is required for the team to innovate and to put Agile principles of Lean Thinking into practice.
• c) Too much autonomy can lead to chaos and delay – more confusion, more conflict, and less consistency.
• d) Alignment is required for consistency and economies of scale and governance.
• e) The Transformational Leader will define a balance which works for the team.

Q4: An inclusive culture is one in which everyone’s participation, opinions and ideas are visibly valued and respected. Which of the following are benefits of an inclusive culture? (Multiple Choices)

• a) Increased Groupthink
• b) Increased Psychological Safety
• c) Increased Growth Mindset
• d) Increased Transformational Leadership
• e) More focused OKRs

Q5: In any change to new ways of working we tend to find that about 16% of people impacted are keen to change, whilst 68% are slightly dubious or worried – and about 16% are really very negative. Which of the following are reasons why employees might be resistant to change? (Multiple Choices)

• a) Fear
• b) Time pressures
• c) The last change didn’t go well
• d) Knowing what is in it for them
• e) Training courses

Was it easy? Or difficult? Please send us your answers.

(Credit to Niki Mossman who provided the quizzes)

Now, let’s move to the main topic. In our Dojo White Belt Master Class, we start from DevOps Culture Pillar. The very first story we tell is about an airplane crash. However, you may be wondering what an airplane crash has to do with culture?

The Ethnic Theory of Plane Crashes

In his book “Outliers”, Malcolm Gladwell challenges the existing notions of where success comes from and proposes new models as prerequisite for success like social context, being at the right place at the right time and culture.

To emphasize the impact of culture on success he uses examples from aviation.

One example is the Korean Air Flight 801 plane crash.

In August 1997 heading from Seoul to Guam with 254 people on board, the plane experienced some turbulence and bad weather conditions. There was heavy rain in Guam so visibility was considerably reduced, and the crew attempted an instrument landing. Instrument Landing System (ILS) for the runway they were headed was out of service. However, the captain believed it was in service, and he also managed to pick up a signal that was later identified to be from an irrelevant electronic device on the ground. The crew noticed that the aircraft was descending very steeply and noted several times that the airport “is not in sight.” Despite protests from flight engineer that the detected signal was not the glide-slope indicator, the captain pressed on, and the aircraft crashed into a hill.

Korean culture is a high-power distance culture which means there are higher levels of inequality and are more willing to accept that without question. These cultures tend to value tradition, community, and strict social rules about where a person fits in society. It is uncommon for subordinates to question their superiors. So, the crew didn’t dare to question the decision of the captain which had fatal results.

Similar example is the Avianca Flight 52 plane crash.

In January 1990 heading from Bogota to New York with 158 people on board, the plane ran out of fuel. After they have missed their first landing approach because of low visibility the air traffic controller asked them to circle around to queue behind other approaching planes. The crew failed to communicate the urgency of their situation and didn’t once mention the fuel problem to the traffic controller.

The crash investigation concluded that the problem was caused by language and cultural barriers. While discussing the urgency of the situation in Spanish among themselves, the Colombian crew failed to communicate this to the traffic controller in English. The Colombian culture is a highly masculine and high-power distance. This high masculine and macho attributes of their culture might have led to the crew’s reluctance to ask for help from the New York controllers when they knew they were in trouble.

The conclusion Gladwell makes here is that cultural heritage is a powerful factor in why some people and organizations succeed and others do not.

What is culture?

Culture is, broadly defined as the social heritage of a group (an organized community or society). It is a pattern of responses discovered, developed, or invented during the group’s history of handling problems which arise from interactions among its members, and between them and their environment. These responses are considered the correct way to perceive, feel, think, and act, and are passed on to the new members through immersion and teaching.

Our colleague Falguni Desai put this precisely in her Forbes’s article:

“Culture is a fuzzy word. Some companies mistake culture for beanbag chairs and free soda in their pantry. Others point to flex-time policies and work-life balance achievements. It is neither. Rather, culture is the unspoken, but understood, way things are done, the way decisions are dealt, the under currents which determine what gets prioritized and the invisible measure tape by which actions are rewarded. It’s all of the things that are not in the human resource policy manual, but become institutionalized through repeated, yet subliminal reinforcement.”

Culture is not only a fuzzy word, but also one of the hardest and slowest to change in human society and any organizations. With the pandemic, our nature is shaking from the core.

Culture in DevOps

Patrick Debois is best known as the founder of DevOpsDays and as a creator of the DevOps movement: “That the word DevOps gets reduced to technology is a manifestation of how badly we need a culture shift.”

If you look at over 12 years of DevOps transformation in industry, the organizations finally realized in 2021 that DevOps is NOT about CICD, but about Culture Transformation.

Culture is so important in DevOps transformation, but many companies and organizations have had hard time measuring their DevOps Culture. As the old saying goes, “Not everything that counts can be counted; Not everything that can be counted counts.” Culture is one of few things that is so hard to count but absolutely counts.

Culture and People in DevOps Dojo

Gene Kim once said: “DevOps is a journey full of challenges, and rarely are those challenges simply due to the wrong technology or the wrong processes. In fact, the biggest and most difficult obstacles tend to be cultural. And if you get the culture wrong, even if you get everything else right, you’re headed for frustration, extra cost, and likely failure.”

So, when we define our mission, we put a significant emphasis on culture, as the DevOps culture anchor everything we do.

• 1) Solve the hardest problems in DevOps
• 2) Accelerate DevOps Culture
• 3) Make DevOps Real

In short, the hardest problems in DevOps are people, mindset, and organizational issues; the only way to accelerate DevOps culture is to walk the talk; and we can only make DevOps real by living in the DevOps culture and mindset.

We understand that culture determines:

• What is acceptable or unacceptable
• What is important or unimportant
• What is right or wrong
• What is workable or unworkable
• Who you hire, fire, promote or demote
• What to encourage and what to discourage

What does this mean in real life in the Dojo community? Culture in a community is created by the members of community; the more influence a member has, the more impact he or she can make to the culture of the community. Since culture is so important, we consciously encourage and discourage certain behaviors in our community.

What do we encourage?

We believe that there are enough smart people in Microsoft so we can pass up the smart jerks and wait for a smart, nice person to come through our community. When we do this, we build a community and a culture where people enjoy their cohorts and where we look forward to coming to work in our community every day. As a result, we encourage and welcome those people.

We have a young colleague who has speech impediment. In a highly competitive and fast-paced environment like Microsoft, his struggle to speak in public was enormous. He found a home in the Dojo community because we prioritize real contribution and innovation over mere talk. He became the most innovative Dojo in our community; he won many awards with nominations and support from our community. His resilience and dedication won the highest respects from Dojo team. He credited his success to our culture where an inclusive environment was created for everyone to be heard, and where everyone carries the team along and always has each other’s backs. In this example, we encourage inclusiveness, diversity, and differences regardless of one’s personal limitations.

Dojo has people from all walks of life, but the most difficult region to collaborate with is Australia, as its time zone makes it difficult for people in the region to attend any calls given that the organizers normally try to accommodate most people in the US, Europe, and Asia time zones. We found a gem in Australia despite the time zone challenge. She started to contribute since 2019, she plays back the recordings from each scrum call, she replies to inquiries from all regions, she is the most dedicated innerSource maintainer, she is the leader of Dojo delivery and offering, and she provides feedback for various write-ups and presentations. All is done through remote asynchronous communication. She represents the very best of our community, and people called her an icon and a legend in a recent readiness event in a US time zone. She did everything without any funding and with the highest quality. The community felt she gave too much, so they decided to nominate her for the highest award in Microsoft known as the Platinum Club and she won. In this example, we reward dedication, consistency, and quality regardless of your region.

What do we discourage?

On the other hand, we also believe that bad actor would be a personal turn-off as they would do damage within the community. The higher that person rises, the larger the circle of responsibility and influence, the greater the damage would be.

Despite how much we talk In Dojo community about transparency and removing silos, we are still human, and people have their own agendas even within a healthy community. We sadly experienced silos within the community, some of which were even created by the core team members. One way people could create silos was through getting funding from their own organization, then bringing it to the Dojo community to find people who could do the work to serve their own organizational needs. Getting funding for the community is great, but sometimes their agendas were in great conflict with our bigger mission, so they created confusion and division. At the time it was painful, so we had to make the decision to confront this behavior to make sure it didn’t further impact our culture. Eventually the initiatives like this failed on their own terms. In this case, we strongly discourage personal agendas that conflict with the bigger Dojo mission as to not damage our healthy culture.

Many people came to Dojo for various reasons including personal growth, networking, learning, etc. However, one of these reasons includes self-promotion. The self-promoters had no interest in developing other people, but only achieving personal self-fulfillment. They might have been able to meet their targets and get things done, and they knew how to manage up, but the feedback that came from peers, people level below them, and external contractors highlighted some real issues and problems. The number of those people are very few in our community, but we must be concerned even if there is only one, as we must discourage anyone with a “look-at-me” attitude. If we don’t weed out the bad behaviors, their influence will slowly and gradually spread out and cause grave damage when it is too late to fix.

In Summary

We believe one of the most important responsibilities of this community is to create the right environment and give members development opportunities that enable them to realize their full potential. There is an interesting fact about koi – the national fish of Japan, they will not grow to their tank size and then stop. If you keep it in a small fishbowl, it will grow to be only about two or three inches long. If you place koi in a larger tank, it will reach six to ten inches. If you put it in a large pond, it can grow as long as a foot and a half. However, if you put it in a large lake, it has the potential to reach the size of up to three feet. Like the koi, we will grow to the dimensions of our boundaries. In DevOps Dojo, we have seen some people grow exponentially in a short one to two years, like koi, this environment allows them to reach their full potential.

How can we create such an environment? Fundamentally we don’t try to scale the process, but rather scale leaders in DevOps Dojo, and this is aligned with Marty Cagan’s view. At the core, we look for people with high emotional intelligence, high integrity, and consistency. We are less focused on technical skills because Microsoft hires highly technical competent people, brains and the capacity are givens, so the basic quality is already there.

As the old saying goes: “A good environment makes bad people good, and a bad environment makes good people bad.” When we promote integrity-based, human-centric, and consistent Dojos, it sends a message to everyone that this is what is being respected and appreciated in our community, and creates a positive environment, that discourages bad behaviors.

Mindset in DevOps Dojo

In the Dojo community, we run into conflicts every day. Each conflict is different and unique, so how we respond to and resolve conflicts will limit or enable our success. Let’s look at the Thomas Kilmann Conflict model for handling conflict in Dojo community, and how this model influenced our thinking and growth mindset in the context of DevOps transformation.

The Thomas-Kilmann model identifies two dimensions people fall into when choosing a conflict resolution strategy: assertiveness and cooperativeness. Assertiveness involves taking action to satisfy your own needs, while cooperativeness involves taking action to satisfy the other’s needs. At the core, you must decide which one is more important in any conflict: outcome vs. relationship.

1. Avoiding
2. Accommodating
3. Compromising
4. Competing
5. Collaborating

1. Avoiding – Conway’s Law

When you use a strategy of “avoiding”, you mostly try to ignore or sidestep the conflict, hoping it will resolve itself or dissipate. This is when you simply avoid the issue. This works when the issue is trivial or when you have no chance of winning. It can also be effective when the issue would be very costly. It’s also very effective when the atmosphere is emotionally charged, and you need to create some space. Sometimes issues will resolve themselves, but “hope is not a strategy”, and, in general, avoiding is not a good long-term strategy.

Conway’s law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1967. The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interface structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult.

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” – Melvyn Conway

We use the strategy of avoiding when the conflicts in Dojo are at odds with Conway’s Law. Since it is a law, when we handle conflict by going against the law, the coordination cost is too high, and eventually it significantly discourages people involved, leading to failure or unsatisfactory consequences.

Dojo started as an internal initiative to transform our own service organization into a community of practice. People came from various organizations including GitHub, product groups, Customer Success, professional services and so on. We practiced DevOps, built IPs, and conducted internal live readiness. When customers heard about our Dojo master class practices, they asked if we could deliver these to them before we even had an offering because it was precisely what some customers wanted. On the one hand, we never wanted to go too fast in offering the Dojo master classes to customers. We understand that because this is a culture transformation, the master class itself will not maximize the culture impact; it needs to be integrated with a broader set of services to truly transform an organization. On the other hand, it is a lot harder to put together a cross-organizational offering precisely due to Conway’s law. Therefore, we largely avoid the offering topics, but only work with a small number of customers who really appreciate the values of Dojo Master Classes and go deeper with their DevOps transformation.

2. Accommodating – A/B Testing

When you use the strategy of “accommodating” to resolve conflict, you are essentially taking steps to satisfy the other party’s concerns or demands at the expense of your own needs or desires. Accommodating is effective when the other party is the expert or has a better solution. It can also be effective for preserving future relations with the other party.

Confirmation bias is the tendency to search for, interpret, favor, and recall information in a way that affirms one’s prior beliefs or hypotheses. We all fall in love with our own ideas. As humans, we are not capable of assessing how good our ideas actually are. We need a scientific method to test and measure how much value a product improvement would actually bring, and we must test our product ideas.

Source: https://i.pinimg.com/originals/6b/9b/aa/6b9baa99e5a1398355e976a2856e655b.png

In Microsoft, we have many smart and opinionated people, so debate is common in the Dojo community. We would sometimes become exhausted debating each other with no one being able to convince the other side. If we let this go on without a constructive approach, it could result in sabotage between the two parties. Therefore, at the early stage, we decided to use A/B testing, which means that we proceed with both approaches, and let consumers of the solution decide which option is more suitable. This approach always works well in the end, even though the final solution was often not solution one or two, but the combined and better solution three. In Dojo, we test if it is valuable for consumers, useful for users, feasible for engineers, and viable for our business. When we lay out the process and rules, people can become quite productive as they focus not on personal agenda but on business outcome.

A recent example of A/B testing comes from worldwide readiness planning in Customer Success business unit. Since each region is different and their capacity of taking time off from work is different, we decided to do A/B testing. The America time zone takes a full 5 days a week schedule. Europe takes a full 10-day schedule. Asia takes 2-week half day schedule. The Asia schedule has been tested many times internally and externally, but the America and Europe schedules have not yet been tested. This is important, especially since America’s schedule can be really tiring and non-sustainable.

We just finished America’s readiness with exceptional success even though it was the least favorable schedule by our standards. What we found out in this class was that the audiences are mature and experienced, so they preferred lots of real-world discussion over hands-on labs. We provided the best of America’s trainers to coach this class, and the shorter time worked out quite well for the participants.

This is a classic example of confirmation bias because we imagined that this model would not work according to our calculation, and we tried to find more reasons to discourage this option at the beginning. At the end, however, we reminded ourselves to do A/B testing, as we would have no idea of the consequence until we had gone through the process at least once.

3. Compromising – Economies of Scale vs. Economies of Flow

The strategy of “compromising” involves finding an acceptable resolution that will partly, but not entirely, satisfy the concerns of all parties involved. Compromising is the “lose-lose” scenario where neither party really achieves what they want. This requires a moderate level of assertiveness and cooperation. It may be appropriate for scenarios where you need a temporary solution, or where both sides have equally important goals.

One of the most tense decisions in any business, whether we recognize it or not, is deciding where we need to be on the spectrum between an “Economies of Scale” or an “Economies of Flow” approach.

In business, economies of scale are financial advantages that a company gains when it produces large quantities of products where achieving the lowest unit cost of production is the primary goal. Within markets of huge demand, economies of scale are very powerful. On the other hand, economies of flow aren’t nearly as concerned with money as are their economies of scale opponent as speed is their primary goal. How responsive are we to the customer? How can we deliver something that the customer wants NOW?

In the Dojo community, we studied DevOps history and the fundamental issue of DevOps in depth. As much as most organizations and leaders want to start scaling as soon as possible, it is a mistake to do so because they don’t understand the core problem of DevOps. DevOps is about information flow, so before organizations can truly scale DevOps, they must ensure flow. In other words, we must first take care of economies of flow before economies of scale. Otherwise, you scale more silos, more rigorous processes, and more control, which is precisely the opposite of DevOps culture.

In Dojo, we confronted two schools of thinking in readiness of our internal training. This was discussed in this DevOps Dojo – Experiential Learning Blog. We have run three-years of Internal Dojo master classes in live settings (on-site and online) averaging an over four and a half out of five- star rating. People learned so much from coaches and peers about mindset change and team building, which are the most important parts of the live delivery. However, this is not considered scalable by another school of thought that insists that live delivery is too expensive and has too little impact on organizational metrics.

In this case, we compromised. People who believe in live delivery continue to pursue the “expensive” approach with funding, and for those without options had to take a MOOC self-study. In fact, we think the best way would be to let the consumer decide which approach is more suitable for them, and then adopt that approach based on the data collected from surveys and usage. We think we should have a more comprehensive approach because one size never fits all. The right mindset of making the decision should be based on outcome (human impact) rather than of output (vanity metrics).

As the culture transformation continues in our organizations, we have seen that one very positive thing about our culture is psychological safety – which we will discuss in the following section. Despite the heated debate and division on the readiness conversation, we continue to test our hypothesis without fear. Unfortunately, this is not true for every company. Let’s dive into psychological safety which is the one of the most important culture elements in the DevOps transformation. A lack of psychological safety will most likely lead to frustration, bitterness, risk aversiveness, and failure as you eventually lose your organizational agility and market competitiveness.

4. Competing – Psychological Safety

Someone who uses the conflict resolution strategy of “competing” tries to satisfy their own desires at the expense of the other parties involved. You act in an assertive way to achieve your goals without seeking to cooperate with the other party, and possibly at the expense of the other party. This approach may be appropriate for emergencies when time is of the essence, or when the stakes are high, or when you need decisive action because the result is more important than relationship in these instances.

Psychological safety is about being able to act and engage in a team without fear of negative consequences. It is a shared belief held by members of a team that the team is safe for interpersonal risk-taking. Thus, psychological safety is about the assurance that no team member will be humiliated, laughed at, or punished for posing questions, speaking up with ideas, concerns, or mistakes. It is about daring to engage oneself without fear of negative consequences concerning neither one’s self-image, status, or career. Creating psychological safety is about giving candid feedback, openly admitting mistakes, and learning from one another.

At the early stages of DevOps Dojo, the very first thing we had to decide and agree on was the DevOps taxonomy. Like any complex and matrix-based organizations, we had many versions of DevOps taxonomies based on various organizational metrics and preferences. This not only caused a lot of internal conflict, but also customer confusion depending on which group you worked for. Therefore, the first step was to align a single DevOps taxonomy. We had a relatively easy alignment with six out of seven organizations, but the last one was extremely difficult because they had a taxonomy in place for a couple of years that was used by internal delivery organizations.

The significant gap of this existing taxonomy came from a lack of focus on culture with too much focus on technology. In our new model, culture and mindset is the most important part of DevOps, and this is reflected in everything we do. By lacking the most important part of DevOps, we were missing the soul of DevOps. This was a rare case where we knew we had to use the competing approach in dealing with this conflict. Because the stakes were so high, if we missed the opportunity, we would lead the organizations down the wrong path past the point of no return. Between the results and relationships, we had to choose to compete for the results. Of course, we understood the challenge of changing the existing taxonomy because many IPs and processes were built on the top of this taxonomy, and changing this taxonomy means changing many things in the existing system.

We had heated debates for months, which went from polite discussions from both parties to bringing more influential people from Product Groups as tie breakers to escalating the conflict to the VP level. In the end, we agreed to adopt the new model. To this day, this was the most important decision we made in our community. With this taxonomy, we covered everything required for DevOps, and brought clarity for everyone, so it served us well in the past and will serve us well in the years to come.

None of this would have been possible if we didn’t have psychological safety in our organizations. Please note that psychological safety at work doesn’t mean that everybody is nice all the time. It means that you can embrace the conflict and you can speak up, ask naïve questions, disagree with the way things are to create ideas that make a real difference, and know that your team has your back, and you have their backs.

5. Collaborating – Aligned Autonomy

Using “collaborating” approach means finding a solution that entirely satisfies the concerns of all involved parties. Collaborating is where you partner or pair up with the other party to achieve both of your goals. This is how you break free of the “win-lose” paradigm and seek the “win-win.” This can be effective for complex scenarios where you need to find a novel solution. This can also mean re-framing the challenge to create a bigger space and room for everybody’s ideas. The downside is that it requires a high degree of trust and reaching a consensus can require a lot of time and effort to get everybody on board and to synthesize all the ideas.

To have aligned autonomy is to have alignment at the top and autonomy at the bottom. The teams need autonomy because that is what drives them to come to work and deliver great results. At the same time, however, their work must be aligned with the business. If there is too much control, nothing gets done because no one wants to work there, and it is not a fun environment to be in. In fact, it can be a disaster. One the other hand, if there is too little control, it can be chaotic because everyone is building whatever they want, there are no end-to-end scenarios, customers are frustrated, and nothing makes business sense. Understandably the leaders are always striving for the right balance.

Two years after GitHub joined Microsoft, people were still confused about the strategy between Azure DevOps (ADO) and GitHub at field level, despite endless communication on the strategy and many mini sessions about GitHub. Part of the reason was the resentment from those who had spent over four to five years of dedication in ADO. There was significant investment in ADO from the company and practitioners, so in some sense, it was painful for people to accept this reality. Giving this, how can we change this mindset and communicate the message and strategy clearly in a way that is easier for people to accept this direction?

We had to consider a few complex aspects. Individual small sessions didn’t make people accept the direction and strategy easily, so there needs to be a well-thought-out holistic view of GitHub approach in relation to ADO. Those who present can’t be from the GitHub organization as people would consider them to always be biased toward their products. Presenters must be from outside of the GitHub product group, and ideally from a community that spans organizations and has had no previous experience in GitHub so that it would be more convincing and genuine. Finally, in this remote world, it is hard to keep people’s attention in check because they have a million things on their plate, so the event needs to be integrated with gamification.

To increase the success rate of this initiative, the planning team spent almost three months to work out the aligned autonomy for all involved.

The alignment includes:

• The end-2-end design of the agenda and detailed topic in each session.
• The overall message and direction embedded in each session
• A single storyline and lab that goes through all 6 sessions
• Gamification with quizzes required and awards for each session
• All sessions presented by Dojos along with real-time Q&A by GitHub
• The sessions are hosted by the company-wide DevOps SHOTs team

The autonomy includes:

• Each team owning their own content and labs
• Each team selecting their own team members
• Each team performing their own rehearsal and labs
• Each team deciding their own quizzes
• Each team deciding their own storyline personas

This event was the most successful event so far in our Dojo community and it shows that aligned autonomy really works for all parties if we all work towards to our common goals and the people involved really live in the DevOps culture. As a result, we are invited to present our GitHub bootcamp series in YouTube Live in February 2022!

Final Thoughts

Our CEO Satya Nadella stated that the C in CEO stands for Culture. He said, “The CEO is the curator of an organization’s culture. Culture change means we will do things differently. Our ambitions are bold and so must be our desire to change and evolve our culture.”

The culture changes in the Product Group produced amazing outcomes as shown below.

In DevOps Dojo at the micro level, everything we do is sensitive to the DevOps culture we want to create; this is reflected in every decision we make, every event we take on, and every conflict we deal with. We ask ourselves if our action accelerates DevOps culture and makes DevOps real or hurts DevOps culture and makes DevOps fake. Despite all the challenges we have faced in 2021, we have accomplished 41 (20+21 coincidently) impactful initiatives that were only made possible by our Dojo culture.

In next blog, we will discuss the DevOps Dojo – Product-Centric Model we have adopted in DevOps Dojo.

Special Dedication

This blog is written and reviewed by the following authors in Dojo Community.

• April Edwards – April.Edwards@microsoft.com
• Beste Altinay – Beste.Altinay@microsoft.com
• Mai Nguyen – mainguyen@microsoft.com
• Kan Tang – kan.tang@microsoft.com