In my last post on the SQL Server China R&D team, I brought up culture as one of the most important leadership challenges in building up a team. How do we ensure that a team grows up with the “right” culture? And what exactly is this “right” culture anyway? In this post, I want to delve into these questions in a bit more detail.

Let’s start with the definition of the word first – Merriam-Webster defines culture as

Main Entry: 1cul·ture Pronunciation: 'k&l-ch&r
Function: noun
Etymology: Middle English, cultivated land, cultivation, from Anglo-French, from Latin cultura, from cultus, past participle

the integrated pattern of human knowledge, belief, and behavior that depends upon the capacity for learning and transmitting knowledge to succeeding generations b : the customary beliefs, social forms, and material traits of a racial, religious, or social group;  c : the set of shared attitudes, values, goals, and practices that characterizes an institution or organization d : the set of values, conventions, or social practices associated with a particular field, activity, or societal characteristic

So, culture is about shared attitudes, values, goals and practices. Every organization has a culture, whether one that has been fostered intentionally, has evolved in a grass-roots manner or some combination of the two. Sometimes, organizations are very explicit about verbalizing the kinds of values and cultural attributes they would like to foster. But it should be no surprise that most people cannot understand, or even remember, what the “mandated” culture of an organization is supposed to be. Each of us grew up with some cultural background, but probably not many of us would say that we acquired our cultural leanings by reading a set of values in a document. Most of us imbibe culture through our daily lives, through everyday experiences, actions, reactions, positive and negative rewards and reinforcements, from a variety of quarters – our elders, superiors and peers. Over time, these values and patterns of behaviors become ingrained in our very being and we then become part of the “established culture”, doing our part in passing that culture on to others in the organization.

Research shows that culture, once ingrained, can be very difficult to change or “unlearn”, for individuals and even more so for groups or organizations. At the same time, over the long term, culture has been shown to be a much more reliable and important factor that differentiates successful organizations from average or below-average ones, much more so than business strategy, a particular technological or process advantage, or even particular leadership howsoever charismatic or visionary it might be. That is why it is so important, IMHO, to start off a team with the “right” culture, howsoever each organization might define right.

For a team such as the SQL Server R&D team in China, clearly a lot of the “right” culture for us follows from the culture of our “parent” team in Redmond. Of course, we will interpret and adapt and bring our own local flavor to this culture here in China, but many of the essential characteristics that define who we are and how we behave we will inherit from the larger SQL Server R&D team. So what are some of the elements of this “SQL Server culture”? It is hard to give a definition or boil down to a few bullet points to things that have been accumulated over a period of many years, but let me try to list here a few things that I believe are core to the SQL team:

Systems Culture: We are a systems team. We build mission-critical platform software which is used by tens of thousands of organizations to build and run business-critical applications that are in turn used by hundreds of millions of people world-wide every day, 24 hours a day, 365 days a year. We build software that has a lifetime of years, indeed decades. Any mistake or weaknesses, whether in design or implementation or in our processes or methodology, can and will show through. The bar is high! To be successful in this kind of an environment, we need a mind-set of being professional grade engineers (see below). Amateurs need not apply!

IC Culture: Building mission-critical systems software is a craft that takes years to learn. We often tell engineers when they’re hired, especially those coming straight out of universities, that they won’t even be fully productive until 3 to 4 years into their job! While this might sound hyperbolic, it is actually true. By the time an engineer learns what customers want, how to translate that into a product or feature, what is good design versus bad design (versus great design), what tradeoffs to make, how to write robust, secure, reliable, scalable high-performance code that is maintainable and supportable in the field, and to do all this in a productive way working in a team environment, it is going to be several years. This is the process of transforming a smart fresh graduate into a professional grade engineer and there are no short-cuts.

So what is IC culture? IC is Microsoft-speak for Individual Contributor – as opposed to lead or manager. When a business depends on deep technical skill and knowledge like ours does, we have to value the individual contributor. We cannot build a product like SQL Server if every smart engineer wants to stop writing code 4 years into their career and start only managing people. I often cite this statistic – Microsoft has dozens, perhaps hundreds, of VPs world-wide, but only 14 Technical Fellows (and we are fortunate to have 2 of those in SQL Server). The take-way is not that a VP is not an important post, but that at Microsoft, and definitely in SQL Server, we very highly value people who want to remain technical through their career. In a way, Bill Gates himself is the ultimate IC – sure he has a staff, but his main role as Chief Software Architect (CSA) of the company is to help chart the technical direction for the company. There can be no greater testament to the value placed on ICs and deep technical knowledge in our environment.

In fact, I believe this point is so fundamental, I’d like to step back here for a moment from SQL Server or Microsoft or any particular company. In my travels around the region, many people express a belief/hope that the Asia-Pacific region as a whole and in particular countries such as China and India shall increasingly take on the mantle of technological leadership in the world economy.  Obviously there is a wealth of talent in this region that provides the necessary conditions for this to happen. However, there is also no doubt in my mind that if this region is really to get to that next step where long term product and industry innovations are being driven from labs and companies here, we have to create a culture that values deep technical achievement. In today’s environment, when I talk to college students about their career aspirations, 8 out of 10 want to be managers within a few years of graduating. We simply cannot expect to build the next generation of technological leadership on such a foundation. I see valuing deep technical knowledge and the IC culture as an imperative for the entire eco-system in this Asia-Pacific region, not just for a particular company or group.

Innovation culture: The database industry is a mature one: 30+ years, 20+ billion USD in annual revenues world-wide. It’d be easy to think that innovation is not a driving force in this industry at this stage. You’d be dead wrong! In my earlier post on the transformation from Database to Complete Data Platform, I described the unprecedented breadth and depth of challenges facing our field. To tackle these challenges successfully, innovation needs to be a core value in our genes, or else we’ll be extinct soon enough. Innovation can be big or small, technological or process oriented, but innovation needs to be a daily value that every employee lives and breathes. SQL Server has had a history of innovating in ways that fundamentally changed even this mature industry – pioneering ease of use and auto-management, integrated BI capabilities in the core platform, dramatically simplified developer experience. Today, we continue that tradition with many break-through technologies in the next release of SQL Server such as the Entity Data Model. We will absolutely need to continue to this focus on innovation going forward.

Customer-focus: In today’s super-charged environment, it is easy to focus on the competition and forget about the customer. But it is vital to understand that the way to beat the competition is by serving your customer, not the other way around. Customer-focus is not the job of one particular department or role. Sure there will be customer-facing departments like our Customer Support Services (CSS) and various other field organizations. But customer-focus is vital to job of every single individual throughout the organization. Without knowing what the customer ultimately wants, you cannot do your job properly – regardless of whether you are a developer, tester, program manager, architect or even an admin! There is no easier way to become obsolete than to lose touch with what the customer wants. On our team, it is mandatory for every employee to spend some portion of their time with customers, whether it be through participation in newsgroups and forums, attending customer conferences, or a variety of other ways.

“Do the right thing”: I could go on about other values we cherish within SQL Server and Microsoft, such as respect for diversity, being open and honest yet respectful, taking on big challenges etc. While these are all great values and ones we do indeed cherish, if you talk about everything you talk about nothing. So I would like to conclude by focusing on a summary value that I call “do the right thing”. I admit it may sound a bit sappy, but it is true that this is something we strive hard to live by in SQL Server. Whether it is with regard to a customer issue, a product issue or an internal issue, this is a motto that guides us in our day-day work. I’ll give you a couple of examples. I’m sure every SQL Server customer remembers the Slammer worm to this day. This one event completely changed our approach to software development within SQL Server. When the worm hit, we had actually just gone through a security push and released SQL Server SP3 (which actually included a fix for the exploit used by this worm). However, once this problem hit, it was no longer a question of whether we had issued a fix or not. We had to help our customers get their systems back up and running as quickly as possible in a safe way. The SQL Server team mounted a Herculean effort in the short term to produce the tools and guidance needed for customers to recover their systems. But it is the long term changes we made – in our development processes, in our disaster-preparedness, in our entire approach to security – that stand out in my mind. The results of those efforts have proven themselves over the last several years as SQL Server has proved itself to be one of the most secure products on the market. Does this mean we will never have a vulnerability or an exploit again? Clearly, the answer is no. But what we can say is that we’re working hard every day to make that as unlikely an event as possible, and we’re also constantly prepared to be ready to respond if such an event does occur again.

Another example I’ll cite is the case of the Database Mirroring (DBM) feature in SQL Server 2005. As one of the most important and popular features in the release, clearly there was a pressure on us to ship this feature. However, as we got close to the end-game of shipping SQL Server 2005, it became clear to us that we would not have the time to run this feature in production (both internally within Microsoft and at selected customer sites) for the duration we would need to have a crucial high-availability feature like DBM be certified for production use. So we had a difficult set of choices – delay the release, ship DBM anyway, or pull the feature from the release. None of them were easy choices – if they were, we would not be talking about them. But in the end, we decided the right thing to do was to ship SQL Server 2005 but not certify DBM for production use, complete the production-test runs in due course, and then certify DBM for production use with SP1. Sure, there was pain associated with this decision in the short term, but looking back customers now tell us they appreciated the extra care and effort that we put in to make sure the feature was completely ready before we let them use it in production.

Hopefully these couple of examples give you an idea of what we mean by “do the right thing.” There are so many more examples that come to mind but this post is long enough already. I hope you also got a sense for what we mean when we say “SQL Server culture.”  It is going to be an interesting challenge to make sure our SQL Server China R&D team grows up with the important elements of this culture ingrained in us as we grow the team over the next few years. But that is a core part of the commitment we made when we decided to create this team.

Until next time – cheers and zai-jian!

Prakash – 孙博凯