In my years working with technology people, I have come to classify them in two basic categories - "Builders" and "Maintainers". I believe that identifying these types of people is one of the keys to building good teams and running successful projects.

Please note, first of all, that I am not labeling these as good or bad, hard working or lazy, smart or foolish, etc. - all of those variations can be found in both categories of people. This distinction is primarily about the strengths and weaknesses of two personallity types.

Also note that like most "stereotypes", these are generalizations.  Most people have some blend of both personalities, but lean in one direction or the other.

Builders

Builders are people who love to innovate, and thrive on revolutionary change.  They are the architects, designers, and developers.  They enjoy a challenge, and despise being put into a box.

Builders are usually resistant to performing support or documentation functions.  They dislike the mundane or the repetitive.

Builders often become tired of a project when it is about 80% complete – when most of the innovation is done, and what remains are the fine touches and clean-up.  They are easily distracted by the “next big thing”.

Maintainers

It’s not that maintainers don’t enjoy innovation, but they typically enjoy it on a smaller scale and with less risk involved.  They thrive on routine and consistency.  They take pride in things like uptime, throughput, and “keeping the lights on”.  They are more tolerant of incremental changes and improvements.

Maintainers are not usually great architects or designers, but their input into these functions is very valuable.  They bring a practicality to the builders’ out-of-the-box-thinking.

Pitfalls

Many organizations do not recognize these two different types of people, and make some of these mistakes as a result:

Not hiring the right types of people for the right jobs. Builders make poor support resources, and maintainers make poor architects and project leaders.  When interviewing candidates, it’s important to determine what type of role you are filling, and identify the builders and maintainers in your pool.  Otherwise, you’ll hire a builder for a maintenance job, and he/she won’t last very long.

Forcing builders to support / maintain the systems they build. Many, many companies hire great builders to lead new projects and create new systems, and then expect those builders to be the primary support resource for those systems once they are in place.  Not only do builders usually despise support work, but they are not very good at it.

What often happens is a good builder takes a job, spends a year or so building a great system, and then spends two years trying to do something new while being required to support that system.  The builder becomes frustrated, and leaves for another opportunity to build something without the distraction of support.   This is one of the primary causes of high turnover rates in many IT organizations.

Using maintainers to build systems. Ironically, maintainers do not often build systems that are easy to maintain.  Sure, they may be simple, but they also tend to require some care-and-feeding, and have scalability issues.  These are the systems which are re-architected and re-built every couple of years.

Not investing in a proper hand-off between builders and maintainers. This is really the key to it all.  When you build a system, there needs to be a period of knowledge transfer between the builders and maintainers.  This has to be part of your plan, and it has to be accounted for and funded properly.

A project should not be considered complete until the knowledge necessary to support the system created has been transferred from the builders to the maintainers. Unfortunately, when budgets or timelines are tight, this is usually one of the first things to be cut out, but that is done to long-term detriment of both your team and your system.