69. Marilyn Munster

In some organizations, developers are kings; in others, they are pawns.

The Munsters was a situation comedy television show in the U.S. that began in 1964 and ran for two seasons. The shtick was the uproarious daily life of a family of monsters living in some regular town, at 1313 Mockingbird Lane. The dad, Herman Munster, is a goofy version of Frankenstein’s monster; his wife is a vampire; Grandpa resembles Count Dracula via vaudeville; the son, Eddie, is a young werewolf.

Paradoxically, the Munster’s live-in niece, Marilyn, is a beautiful blonde college student. But the rest of the family doesn’t see Marilyn as beautiful. They see her as completely unattractive. They try to protect her feelings, but they’re actually a little embarrassed by her. One of the central conceits of The Munsters is that Marilyn’s low status is an accident of having been born into this strange family. It is clear that Marilyn would be far more appreciated in any other family in the neighborhood.

Many developers live the life of Marilyn Munster. They work for companies that rely on technology, but their work is largely unappreciated, and they have very low status in the organization. In many such organizations, managers have all the status. The manager holds the responsibility for planning, scheduling, tracking, estimating, and assigning work to technical staff. Planning, scheduling, tracking, and estimating are usually done exclusively by managers with other managers. The developer is a tech weenie, someone who “does not understand” the real hard work of managing the company.

Managers make the big money because they are responsible for choosing which projects to run, and for running those projects as chosen corporate investments. Techies are to put their heads down and build what the managers tell them to build. If they don’t like it, they are free to leave; the managers, along with HR, will find a replacement. The replacement may be a contractor, and the contractor may be on another continent where tech weenies are less costly than at corporate HQ.

There is another variant of this pattern in which Sales has all the clout. After all, the reasoning goes, it doesn’t matter how good your products are if they don’t get sold to customers. The underlying belief in both these companies is that developers are abundant and that one is about as good as another, so they should be paid as little as possible for their services.

There are, of course, companies that take a completely different view of developers. These companies believe that their products and services are differentiated from their competition by quality and innovation. They realize that there is a massive difference in talent and productivity between the top 10 percent of developers and the average developer. They want the best they can get. This results in a culture in which the developer is king, having great latitude over his workload and his approach to accomplishing that work. These developers often define features as well as build them, and they are typically the front-line estimators of development work. Very senior developers can earn as much as team leaders, sometimes more. Most often, but not always, developers are kings in organizations that make software as their product or ship software as a principal component of their product.

There is an extreme developer-as-king culture that is dysfunctional. When the developers optimize their own work and schedule without regard to the impact of their decisions on others, projects can get into trouble. For example, we found a project where the two developers decided that they would frame-up the software—leaving many classes incomplete because they knew they could write them later—and worked only on “the interesting, hard bits.” The rest of the project team, the QA folks, and the tech writers ended up facing a huge spike of work as the deadline loomed, because nothing was done. Nothing was testable and nothing could be documented until suddenly everything was done, once the developers filled in the gaps they had left. The developers had de-optimized the project by optimizing their own work.

If you employ developers, it is worth asking yourself how important quality and innovation are to the success of your organization. At the highest levels, quality and innovation both require truly talented developers. You won’t attract, cultivate, and retain top talent if you treat them as a regrettably necessary cost center to be minimized.

If you are a great developer and are feeling a bit like Marilyn Munster, rest assured that there are other families out there who will show you the appreciation you deserve. Flee the freak show.