A friend of mine told me an interesting story the other night.

My friend—I'll call him Tom—works for a local bioscience company. Tom started out in the lab. Because the service the company offers is customized to every client's exact need, the sales staff usually needs input from the technical staff to close a deal. In the company's infancy, Tom was the star of the lab; he became the go-to technician for sales consultations.

In recent years, the lab has grown. There are enough lab technicians that the company needs a full-time resource to assist the sales team, set up new accounts, and oversee lab operations. The choice was obvious. Tom was promoted.

What struck me about his story was how similar it is to the promotion narrative in the software industry. Tom's story has a happy ending. He's come to enjoy working with clients, and he discovered, a bit to his surprise, that he's good at managing other lab technicians. But things could have turned out differently.

In the software industry, they usually do.

Double Whammy

Maybe I'm selling Tom's company short. Maybe they promoted him not just because he knew the lab work inside and out, but because the sales staff liked him and because he had exhibited leadership skills in the lab that portended his success as a manager. But that's not how software promotions usually happen.

In my experience, the normal course is for a company to select its best programmer, give him a raise and a new job title, thrust him into countless meetings, and saddle him with a bunch of newbies. The idea is that the programmer, who is so great at his job, will be able to help the newbies become just as great. The company sees its action as a short-term sacrifice designed to achieve a long-term gain. It appears logical from a certain angle.

And every now and then, the company gets the exact result it hoped for—indeed, this narrative is my narrative. But such outcomes are the exception.

The typical outcome is grim. First, the company loses its best programmer. The new manager's day is filled with interruptions—sales meetings, project meetings, questions from his staff, task assignment, etc. He no longer has a dedicated block of hours in which anything creative can be done. Second, the company acquires a terrible manager. Our programmer lacks the skills, training, and inclination to be good at his new job. He goes to extraordinary lengths to assign himself interesting coding problems, usually to the detriment of team's overall productivity. The manager works long hours to accommodate the new duties he despises as well as the old duties he can't part with; the newbies don't get the attention and mentoring they require; morale drops precipitously.

Despite its good intentions, the company deals itself two serious blows: it not only loses its best asset, but perversely, it converts that asset into its worst liability.

The Lesser of Two Evils

The astute reader has probably already asked himself this question: If our programmer doesn't want to perform the duties of a manager, why does he accept the promotion in the first place?

I think two things are going on. First, we're supposed to want promotions, right? It's how we recognize success and value. Plus, it usually comes with a pay raise. What kind of lunatic turns down a promotion? Second, both the company and the programmer get seduced by poor nomenclature. The new position is normally given the title Technical Lead, which sounds like a programmer who has the side responsibility of coordinating the output of a team of developers. To a programmer, that extra responsibility is worth the raise, recognition, and cachet. But if the company called the position what it is—Technical Manager—only programmers willing to give up coding altogether would pursue it.

But the problem is even more insidious than this. Traditionally, programmers are offered two career paths. They can become managers (a CTO track) or senior programmers (an architect track). The problem is both tracks terminate in roles that many programmers don't want. One path leads to pure management, the other to systems design work. Where do programmers who actually want to program go?

Elsewhere.

Other Options

Freelance programmers are predominantly of the programming programmer mold. When corporations fail to offer them attractive alternatives, many programmers quit, sign on with placement agencies, and go right back to work for their former employers for more money. I don't see these arrangements as particularly advantageous to the corporation, but amazingly, they seem to like them.

Programmers at small shops are also usually of this mold. Small shops can afford to implement flat organizational structures. Because all managerial positions are permanently filled by founders, programmers never have any expectation of traditional advancement. Instead, the companies offer lots of intellectual stimulation, fewer rules, and better pay.

As the owner of a small software company, I can't say I'm terribly upset about the current state of affairs. It certainly makes it easy for me to acquire talent. More than anything, I'm surprised. I don't understand why large employers accept such a serious and constant drain on their talent. It probably has something to do with all those miscast managers.