If you had to choose between hiring an outstanding candidate with only related domain knowledge and a solid candidate with specific domain knowledge, who would you select? At Microsoft, we generally select the outstanding candidate, figuring a talented employee can quickly learn a domain. That is, unless the employee already works here.
If the outstanding candidate is already a Microsoft employee, then specific domain knowledge generally trumps capability (aside from poor performers). Why are we this stupid? Because we know there are dysfunctional managers who don’t always use the review system properly, so we give candidates the benefit of the doubt, and because we are obsessed with domain expertise. It’s wrong.
A bunch of Microsoft readers are riled up now, denying Microsoft favors domain knowledge over capability for roles. Really? Think back to your last reorganization. Did the most capable or the incumbents get slotted into positions? That’s right—we’re idiots.
Eric Aside
There are many factors for slotting people into roles during reorganization. You must consider continuity, growth potential and opportunity, and a general fairness and morale. There are difficult trade-offs and mistakes are inevitable. Feel better? Good, because those are all noble reasons, but poor excuses.
For all the Microsoft readers who’d deny we favor domain expertise over capability, there are other Microsoft readers who support that bias. After all, we’re all smart, and deep domain knowledge isn’t easily transferred. An engineer with specific domain expertise for the job will be more productive. Right? Wrong.
Deep domain knowledge is frequently transferred. It takes a little while, but a team’s existing experts are usually pleased to instruct an outstanding new team member. If they aren’t or an area is far too complex for even sharp people to comprehend, then you’ve got other serious problems.
Yes, the company consistently hires smart people, but being smart isn’t enough to make someone outstanding. Outstanding engineers who make difficult tasks look easy can do more than write great specs, code, or tests. They know how to understand, influence, collaborate, and get things done. They multiply the performance of those around them. Yet in a reorg or job change, these people are eschewed in favor of those with more domain knowledge.
How do outstanding employees multiply the performance of those around them?
How does Microsoft culture come to perpetuate an obsession of being masters of our domains instead of overall capability? My educated guess is that it starts with how engineers initially differentiate themselves from their peers and influence their teams—they become “go-to” people for some area. (Individual leadership describes this in detail.) We are conditioned to value subject matter expertise from the beginning.
In addition, outstanding engineers differentiate themselves by how they go about their business. Yet Microsoft is primarily a results company—it’s about what, not how. Subject expertise is about what. Thus, expertise has become king.
Domain knowledge is important—you can’t put just anybody in any job. In addition, specialization is necessary at the group level for complex software projects, as I argue in “Undisciplined” (Chapter 4). However, your overall team productivity and capability depends upon more than domain knowledge alone.
Clearly, we don’t need outstanding engineers in every position—there’s plenty of everyday work that solid engineers can do. However, we do need outstanding engineers in key technical and organizational leadership roles. One division that has figured this out is Office.
For years, Office tried to find ways to challenge and reward its best performers by giving them what they wanted—pet projects, incubation labs, and the opportunity to introduce new applications. Then as Office 2007 was wrapping up, the executive leadership of Office decided to try a radical new approach—what if we put our best people on our most critical projects?
In hindsight, the decision to put your top people on your top projects seems absurdly obvious. Of course, it had been done in isolated situations many times before, but Office was breaking new organizational ground at Microsoft by deliberately applying this approach across the entire division. Windows and Windows Phone have done something similar to Office, but in other divisions the practice of actively managing your top talent is still working its way down from the executive ranks to group levels.
Microsoft has long had a talent management process for top employees called “People Review.” Executives discuss how top performers are progressing, their current assignments, and their potential future assignments. However, actual slotting of key jobs is usually left to the divisions to occur within their release cadences, which typically don’t line up with People Review. This relegates People Review to a status report rather than a Microsoft-wide talent management exercise.
How bad can it be to put perfectly solid domain experts, rather than outstanding employees, into technical and organizational leadership roles? Obviously, it’s not catastrophic. Microsoft has been operating this way for decades and has done quite well.
Many outstanding employees rise into key technical and organizational leadership roles without the intervention of a deliberate talent management strategy. We generally hire strong people, so solid folks do fine and ship successful products.
There are two problems: opportunity cost and abandonment.
Strong employees tend to pick up expertise in multiple domains, but often at Microsoft only the primary domain is valued. Skills in collaboration, influence, vendor management, open source, distributed development, talent management, agile development, and other important but secondary domains tend to be marginalized—a tragic loss of opportunity, value, and appreciation.
There are a few things Microsoft employees can do to ensure our best people are taking on our most critical roles:
Domain knowledge is important. Every employee within a division should be a master of his domain. However, when slotting people for key roles, domain knowledge should not be the primary deciding factor, as long as candidates have a track record of picking up new domains. Instead, leadership skills should take precedence and guide us to greater productivity, greater customer value, and greater leadership in the marketplace.
Unfortunately, Microsoft does little to evaluate or track leadership competence, aside from a fairly superficial, midyear manager appraisal that isn’t formally part of our review or reward system. In addition, our engineering interview process has traditionally focused on domain knowledge and only recently started adding clear guidance on other areas of capability. Perhaps this will improve as our HR systems continue to be revamped.