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.
My boy’s wicked smart
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.
Eric Aside
How do outstanding employees multiply the performance of those around them?
- They seek first to understand—the problem, the people, the system, past solution attempts, and proven solutions from inside and outside Microsoft.
- They use their understanding of the entire situation to reassure their partners and construct an approach in which everyone is engaged and committed to the successful outcome.
- They nurture that partner commitment with inclusive decision making, transparency, and trust-driven collaboration.
- With their group of dedicated partners, aligned behind shared goals, they work together to make achieving the impossible a regular occurrence.
You can call it my ghoulish obsession
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.
Eric Aside
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—What’s so special about specialization?. However, your overall team productivity and capability depends upon more than domain knowledge alone.
That is quite logical
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.
Eric Aside
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 is it?
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.
- How much better would our products and execution have been if our top people were actively selected for our critical projects? Of course, there’s no way to know. However, I do love my Windows Phone, and the newer versions of Office and Windows. I guess it’s a lost opportunity.
- How do outstanding employees feel when they lose assignments to solid everyday employees due to a lack of specific domain knowledge? How do they feel when their talents are squandered, even though they’ve quickly picked up new domains in the past? I have many such friends—enough that this feeling is almost cliché. They feel abandoned and unappreciated—not the way you want your best employees treated.
Eric Aside
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.
Tell me what I must do
There are a few things Microsoft employees can do to ensure our best people are taking on our most critical roles:
- If you’ve got an open position on your team, consider the leadership requirements. If leadership is critical, value how candidates influence, collaborate, and get things done over what technologies they last mastered.
- If one of your current technological or organizational leaders is knowledgeable, but not particularly gifted at leadership, demand better from whoever will listen. If a position opens, reach out to great leaders you know—they may not feel appreciated where they are.
- If you’re undergoing reorganization, write to your executives and demand that leadership trump domain knowledge. Don’t accept excuses for less than the best available.
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.
Eric Aside
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.
Be First to Comment