Over the years, I’ve encountered a number of people trying to specialize too narrowly in their jobs, to the detriment of all involved. Here are a few examples of the behavior I see most often…

The Clueless Creative

When our most experienced graphic designer and usability expert left, and we needed to fill the position, we interviewed a self-described ‘web designer’ who only worked in Photoshop! When asked about his HTML, CSS and Javascript skills, he quite seriously replied that, oh no, he didn’t do that sort of thing. No, when he is finished with his very important work, he then hands it off to someone else to do all that dirty HTML coding.

I’ve encountered his type many times over the years, and nothing both puzzles me and infuriates me more. As I told everyone in our group after this encounter, I think that anyone that calls themselves a ‘Web designer’ should be expert at, and fully prepared to do, the following on any given project:

• graphic design, well versed in everything from visual communication theory to the use of specific tools such as Photoshop and Illustrator,
• interface design, well versed in principles of usability and accessibility,
• interface implementation, including advanced knowledge of HTML, CSS, and Javascript/AJAX.

And like everyone else on the team, this person should also be expected to constantly learn emerging tools and technologies like new AJAX libraries and things like Flex. This person should also be prepared to learn new theming and templating engines for various platforms as they are adopted. In my opinion, this is a minimum set of expectations for a person in this position.

I have too often encountered the Clueless Creative who congratulates himself on ‘designing Web sites’ yet never steps outside of Photoshop. Their ‘designs’ reflect this: all flash, and completely unusable.

The Fish Out of Water

The Fish Out of Water is a print graphic designer who has been tasked with doing graphic design for a Web site for the first time without having the proper training. Of course, their skills are a complete mis-match. Although the situation is similar to the Clueless Creative, I have sympathy for the Fish, as they were hired by people who don’t understand Web design, and the Fish may not appreciate the difference either, at first.

I have encountered several internet illiterate, but highly skilled print designers who assume that designing for the Web is really not different than designing a pamphlet. Their designs reflect this, and it becomes a painful process for all involved, and is especially demoralizing for the Fish.

On the other hand, if the Fish survives this experience and is motivated to learn about Web design specifically, being able to work effectively in both media can make them a very important member of the team.

The Rodney Dangerfield Developer

Recently when interviewing two junior software developers, they told me rather sheepishly that while yes, they have experience with HTML, CSS and Javascript, they can do much more than this and would be more interested in doing ‘back-end programming’ exclusively. They were embarrassed to possess these softer skills and wanted very much to be taken seriously as ‘real’ software developers.

The fact is that if you are a Web application developer, you really should be facile in all these areas and more, including knowledge of database design and programming as well as more than one leading framework, and preferably more than one language/platform, depending on your experience level. Rather than be embarrassed that you know softer technologies like CSS and Flash, you should be proud that you are well rounded and can contribute in so many different ways on a project.

Possessing these varied skills makes you more valuable to the team, not less, and is very important in the competitive, demanding world of Web development.

The Self-Defeating Specialist

Another puzzling type is the developer who radically overspecializes in an area, never learning anything new outside that area, and jealously guarding their territory. The apparent motivation here is to become ‘invaluable’ to the organization by being the expert in some vital technology.

But this person is not only hurting the organization by working with blinders on, they are severely limiting themselves. As technologies inevitably change, this person sabotages the organization by fighting for the shifting ground they have built there career upon. As a result, the organization is less flexible, and ultimately the person is forced to realize that rather than becoming invaluable, they have actively made themselves less valuable as time goes on, until finally, their entire skill set is obsolete.

In my organization, we had a developer who allowed to gradually position themselves as the ‘expert’ on a particular vendor’s API. We had made a decision years ago to use this vendor’s product extensively, so specializing in that area seemed to ensure that the person would always be needed by the organization. In the end, when we inevitably abandoned the product, the person was left with nothing, and as that person had fiercely tried to protect their territory in the past, she now had a reputation for being difficult to work with. So, when her skills were no longer needed, and she was ill prepared to learn new skills, management did not hesitate to fire her.

My Attempt to Set a Better Example

I recently started leading six developers in the creation of , the goal of which is to build a fairly complex Drupal based Web site, everyone from the developers to my boss assumed that we would be breaking down work assignments based on architectural tiers: someone would focus on ‘front end’ programming for certain features, another on ‘backend’ programming, etc. I decided instead to make assignments based on discrete features requested by the client and expect everyone to program across tiers.

This made sense to me for several reasons. In a modular framework like Drupal, most of the cross cutting functionality in each tier–the plumbing–is there already, and you either need to install and configure modules, or write your own to add functionality. Each individual feature is relatively small to implement, and dividing small tasks into even smaller chunks for multiple programmers who then have to coordinate their efforts, seems very artificial and inefficient.

This coordination problem exists not only because of things like communication overhead, but also because people tend to have a hard time connecting together separately developed threads in a system. Although it may seem logical to separate coding based on tiers, because each tier may seemingly benefit from specialization, and should theoretically be loosely coupled from other tiers, the reality isn’t this cut and dry even in the best circumstances.

Splitting work based on tiers diffuses responsibility for the deliverable, as those working on each tier tend to have a narrower definition of what is in their tier than others might. So, the ‘web designer’ may not want to do true interface design and usability testing, or they may not want to do any Javascript coding or even HTML coding, even though this may be the expectation of others.

Instead, faced with relatively small, well defined requirements for each feature requested, I wanted one person (or one person, and a backup they could rely on in tough spots) to be responsible for one or a few features. Also, the client put her requests in the form of these discrete features, as you might expect, so this is how she thinks of the system, and having ‘one throat to choke’ helps her communicate with us about the project.

Now of course, features themselves may not really be any more discrete than tiers, and maybe much less so. But in my experience, its easier for two people working on a project to coordinate their efforts across features that have a dependency relationship or some other type of interaction, because the responsibility of who does what is clearer, and each person is invested in the feature they have developed, so they are motivated to further add to that feature’s value in the system.

All in all, this approach has made both planning and communication (both within the team and with the client) easier. It also sends a strong message to the team that being able to develop software across tiers, instead of specializing in narrow areas, is what makes you valuable.