One of the bigger risks facing Linux is that explosive growth can destroy it because people who don’t understand what it’s for often install it simply as a Windows substitute, then discover that it isn’t Windows and denounce it. The underlying issue here is that people can easily become captive to what they know. That happens in almost all areas of management, not just in technology.
It’s perhaps easiest to illustrate this point in the realm of executive head-hunting. Senior executives are usually recruited by committees that first hire consultants to winnow the field to a list of people judged competent and then make a final selection mainly on the basis of the candidate’s social credibility in the role.
Thus, a committee charged with recruiting a new vice president for marketing usually starts with a list of people with the core skills and then gravitates toward the one whose personal credibility with customers and colleagues is expected to do the organization the most good.
Unfortunately, this strategy, which fundamentally replaces “not invented here” as a basis for rejecting new ideas with “not known here” as a basis for rejecting people, can backfire badly because the people making the decision and the potential recruit can form a closed social loop, trapping the organization into taking on someone who cannot break free of his or her former network. The recruit then inadvertently acts like a Trojan, attacking the organization from the inside.
For example, the Canadian sales organization of a well-known American company recently hired a former IBM employee as president because he was widely known and respected in the industry. They expected his name to open doors for them — and it did, except that the doors he opened led to others of the faithful because, of course, those were the people he felt comfortable with.
Because he also knew what they bought from IBM, he focused his new organization on meeting those same needs, turning an effective selling machine for breakthrough hardware and software into one focused on underselling IBM on services. In that process, he lost key people, hired and promoted his own clones, and generally positioned his company to underperform on new sales over the next few years, all the while blinding the head office to his activities by turning in decent monthly numbers on the strength of increased service volume.
The underlying issue here is that he brought his new employer to his existing social network instead of bringing his network to his new employer. This particular individual is on a first-name basis with most of the senior data center managers in the country and had racked up an impressive record as an intermediary in their purchases of IBM products and services.
Unfortunately, his new company doesn’t sell the hardware or software those customers buy. And the people who do buy what he sells don’t know him. Worse, his relative success in selling services among his former colleagues quickly affected opportunities in the company, with survivors polishing up outdated skills and others interviewing elsewhere. Meanwhile, of course, the smaller, more aggressive customers to whom the company generally caters were left to wonder what happened to the enthusiastic sales and technical support they used to get.
For most of the company’s employees and customers, the results were tragic: They see the company rotting from the head down but are unable to do anything about it other than leave or wait until the head office notices.
For the uninvolved, however, there’s a lesson to be learned here and a prescription to be offered. The lesson isn’t about some Machiavellian scheme to destroy competitors by encouraging them to hire your people as Trojans. It’s about the degree to which Linux is exposed to the same fate when Windows experts try to install and use it without changing their ideas about how computing services should be used or provided.
The prescription follows directly from the analogous behavior among executives. It’s true that hiring committees don’t usually care about social networks when recruiting technical staff, but they should.
Thinking Outside the Platform
It’s important to recognize that what drove the ex-IBM employee to focus all his efforts on the same people to whom he sold before was really that he knew no one else. You can see that a Microsoft Certified Systems Engineer who only knows other MCSEs might have much the same problem — and it’s a problem you can help fix.
Specifically, how you do that depends on you. If you’re an MCSE who would like to know more, then read some books, find good some people to talk to and expand your horizons beyond running servers on servers.
If, in contrast, you understand core Unix philosophies like user empowerment or how small, effective programs combine with large-scale systems to produce extraordinary results, then you should spread the word. Become a Unix mentor; find some benighted MCSEs and quietly coach them — but make sure they don’t see you doing it, because that would destroy the effect.
Paul Murphy, aLinuxInsider columnist, wrote and published The Unix Guide toDefenestration. Murphy is a 20-year veteran of the IT consultingindustry, specializing in Unix and Unix-related management issues.