In a previous blog entry, I discussed how N=1 encourages meta-vendors, what a meta-vendor is, and the implications of "meta" for an organization's employee hiring practices. I said meta imposes a premium on talent, skill, and experience. But there's more to it than that.

Theoretically, everyone wants employees who are as talented, skilled, and experienced as possible. But in the real world, organizations get by with less, especially since less is also less expensive. In an N=1 and meta world, that's no longer the case. A meta approach is more demanding of your employees; they must understand the problem domain at a more abstract level. This requires a number of hiring criteria that are not always high on everyone's list:

1. Raw mental horsepower, needed to handle the abstraction meta requires. This kind of work is not for everyone.

2. A good "classical" education, which teaches a person to think, analyze, and solve problems. This is harder and harder to find since the collapse of our educational system. However, a strongly self starting and self-motivating person sometimes achieves the same results on his or her own, so formal educational credentials may not be the best indicator. There are many examples of this among luminaries of the IT world.

3. Deep experience in the problem domain, needed to mentally encompass the meta abstraction of that domain.

As before, I will illustrate with a software engineering meta-tool such as the one we have developed at Pennington. Its target consumer is a senior systems programmer, which means someone who is …

1. Experienced in dealing with the abstractions implicit in compilers, interpreters, operating systems, and utility programs;

2. Usually experienced in several computer languages;

3. Deeply experienced in computer science at a practical level;

4. Experienced in applying software to a broad range of problem domains.

Of course, people like that don't grow on trees, and they're expensive. But look at the payoff: By applying a meta-tool to an organization's software engineering workload, you're applying a large multiplier on the results of the engineer's effort -- much larger than the increased salary expense involved. Furthermore, the meta-tool's automation of software engineering tasks results in far fewer errors than manual programming would, which substantially reduces debugging time and effort, not to mention the risk of failure. The shorter turnaround time the meta-tool provides also encourages agile or extreme programming techniques.

So how does this generalize for fields other than software engineering? Employers may have to break some habits, such as:

1. Hiring cheap to save on payroll expense. The fact is, you can't afford it.

2. Relying too strongly on traditional employee measures such as certifications, degrees, and "time in grade," to the exclusion of talent and achievement. The kind of employee required for N=1 and meta is scarce, but not that hard to identify if you're looking at the right criteria.

3. Measuring success through head count. N=1 and meta encourage small but powerful teams; it's well known that such teams are far more effective than larger teams (Brook's law), even with equally endowed employees. An example of this is the "team leader" approach to programming pioneered by IBM many years ago. My personal opinion is that when a team's number exceeds four or five, you're starting to lose effectiveness.

What does this mean for employees? Get as much education as you can, both formal and informal, with an emphasis on analytical and problem-solving skills. Wrestle with problems involving abstraction, to push your brain in that direction. And, probably most important, play with the tools your education provides. There is tremendous satisfaction in watching your own creation do something remarkable.

The good news is that, as telecommuting becomes more practical and prevalent, the employees described above need no longer be next door; they can be anywhere. That's R=G.