If software were writing Karl would be the kind of fellow who could tell you the name of every book ever written, analyze them for style and didactic content, and describe the inner motivations of each author. He just plain knows his stuff. The problem with Karl (to continue the analogy) is that he can´t string together a sentence that makes sense and his spelling is atrocious. If software were writing Karl might be a professor of literature.
What is Karl then? Last time I heard from him his title was "architect" but really he is a software maven. He loves software and everything about it. He knows the features in the latest point releases of every major product and he has an opinion about whether a release is good or bad. He has ideas about the virtues and shortcomings of several languages and he can find five products to meet any given need in less than an hour. The problem is that like most mavens, Karl is more interested in being the expert than doing the work. Unfortunately most companies actually expect people like Karl to do the work and Karl just can't write code to save his life. Strangely, Karl is the only one unaware of this fact.
People like Karl are extremely rare and extremely valuable. Their knowledge can be vital to a team because they add enormously to the collective information pool. If people need to know something they know where to turn. Karl also asks a lot of questions so he can be counted on to know the person who knows the answer (if he doesn´t know it himself). It´s like having you own corporate librarian, Google search engine, and who´s who listing. You can go ask Karl, "do we have a tool that can scrub barnacles off of code older than a week?" and Karl will answer "No, but Cindy over in the flotilla group has a cool Perl script that she adapted from seaweed to dissolve barnacles older than a month. Maybe you can use that."
The danger is that either management believes Karl is an amazing architect since he knows so much or that Karl feels he should be the architect since he knows so much. This is dangerous because people like Karl are frequently awful architects (Karl definitely is). They are so in love with technology that they have a hard time figuring out how to use it effectively. They are also subject to the influence of fads and anyone who has been around software for a few years knows just how faddish it can be. If Karl was your architect ten years ago you would have had a two-year disastrous experiment with CASE based development. You would have been using J2EE Entity Beans until two years ago when you yanked the whole thing out and replaced it with POJOs (Plain Old Java Objects) and IOC (Inversion of Control). You would still have a lot of XML in your code.
So what job do you give a software maven? One solution I´ve seen is to put them on a standards committee. It´s a position of respect and it puts a good face forward for your company. This is a great idea if your goal is to completely sabotage the standards effort. I suspect Microsoft has figured this out since they appear to have used people in this capacity on many occasions. There seem to be a lot of software mavens on such bodies. This is how we got T.120, ASN.1, and EJB 2.0 to name a few (make your own list). With mavens on the committee you can be darn sure nothing will be left out. There will be three flavors of kitchen sink and a double wide trailer buried somewhere in the spec plus a flight simulator hidden in the example implementation. On the other hand if you want the committee to succeed you had better send someone more pragmatic.
If putting them on a standards committee is not the answer, what is? My current answer (should we find a Karl to work for us) is a title like "Technology Fellow." Pay them a bunch and let them perform the function to which they are best suited: helping everyone else do their job. They will get special research projects to determine how various new technologies might impact the company. They will be told that one of their most important roles is answering questions for other people. They will be invited to lots of meetings and design sessions. They will not, however, be in charge of making decisions for those teams. If you do this you don´t have to lie to Karl. He is valuable and you are giving him the job that makes the biggest impact to the company. If Karl makes 100 people 2% more efficient he is probably not getting paid enough. He deserves our respect and admiration. One thing you generally can´t do, however, is tell Karl he can´t write code to save his life. Sadly, there are a number of similar truths about all of us and I´m pretty sure I don´t want people pointing out those truths to me any more than Karl wants you to point them out to him.
The one draw back with this role is that it will only work for medium or large sized companies and only if they also have a very strong set of technical people (who you may title architects if you wish). The other strong technologists need to have a much more practical outlook. If they know their stuff they will naturally make good use of Karl. If Karl is your only strong technologist, on the other hand, you are in a lot of trouble no matter where you put him.
I guess the moral (as simple as it seems) is that if Karl can´t spell you shouldn´t make him a copy editor.
| 
