Generalizing Specialists: Improving Your IT Career Skills

I believe that to become an agile software developer that you need to move away from being a narrowly focused specialist to become more along the lines of what I like to call a generalizing specialist (a concept I discussed in the book Agile Modeling although I introduced the term in the book Agile Database Techniques). This article is organized into the following sections:

Generalizing Specialist: A Definition

A generalizing specialist is someone who:
  1. Has one or more technical specialties (e.g. Java programming, Project Management, Database Administration, ...).
  2. Has at least a general knowledge of software development.
  3. Has at least a general knowledge of the business domain in which they work.
  4. Actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas.

Generalizing specialists are often referred to as craftspeople, "T-skilled" people, multi-disciplinary developers, cross-functional developers, deep generalists, polymaths, versatilists, or even "renaissance developers".

Becoming a Generalizing Specialist

When you get your first job as an IT professional it is often in the role of a junior programmer or junior DBA. You will initially focus on becoming good at that role, and if you're lucky your organization will send you on training courses to pick up advanced skills in your specialty. Once you're adept at that specialty, or even when you've just reached the point of being comfortable at it, it is time to expand your horizons and learn new skills in different aspects of the software lifecycle and in your relevant business domain. When you do this you evolve from being a specialist to being a generalizing specialist.

Figure 1 depicts a fictional skills assessment of an IT professional, showing how it evolves over time. In this example, the person has solid skills in Java development, and some initial skills in modeling, testing, and database administration (DBA). Then, two years later, they've improved all of their skills, including their Java programming skills. They may have achieved this through training & education, mentoring, or collaborative techniques such as modeling with others or pair programming. Then, three years later their skills have improved further, although it's interesting to note that focus on a new skillset (.Net programming) may have motivated the person to let their Java programming skills go stale. It's incredibly rare for someone to become "super skilled" at everything, more on this later, although it is quite common for a generalizing specialist to become more skilled than either a generalist or a specialist.

Figure 1. How a generalizing specialist's skills may evolve over time.

As an individual it's an incredibly good strategy to become a generalizing specialist. The greater your skillset, the more likely that you'll be in demand and the easier it will be for your to gain employment. Furthermore, you'll likely get better jobs than you would have because of your greater productivity and versatility. Just like you wouldn't have a stock portfolio with a single stock in it (that's an incredibly risky investment strategy) you shouldn't have a skills portfolio with only one specialty.

Just like multi-disciplinary teams are a good idea,
so are multi-disciplinary people.

Why Generalizing Specialists?

There are several reasons why you should prefer to build teams from generalizing specialists:

  1. Improved communication and collaboration. A generalizing specialist is someone with a good grasp of how everything fits together. As a result they will typically have a greater understanding and appreciation of what their teammates are working on. They are willing to listen to and work with their teammates because they know that they'll likely learn something new. Specialists, on the other hand, often don't have the background to appreciate what other specialists are doing, often look down on that other work, and often aren't as willing to cooperate. Specialists, by their very nature, can become a barrier to communication within your team. Another challenge with specialists is that they have difficulty working together effectively with others because they don't have the background to understand the issues that the others are trying to deal with.

  2. Less documentation. Specialists are often motivated to create far more documentation than is required, when all you can do is write use cases then those use cases will end up including information that could be better recorded elsewhere, and very likely require reviews of said documentation when they provide it to other specialists. The implication is that the same piece of information will often be captured by several specialists because they're afraid that they'll lose that information. It's quite common on projects dominated by specialists to see a business rule captured in a user interface specification, in a business rule specification, in a logical data model (LDM), in a UML class diagram, in acceptance tests, and in source code. Clearly there's a chance that the business rule will be described inconsistently (thereby motivating more bureaucracy in the form of traceability) let alone the obvious overhead involved with reviewing and maintaining each version of it. A generalizing specialist will write less documentation than a specialist because they have a greater range of options available to them. Instead of having a user interface specialist capture the rule in a screen specification, the data specialist capture it in an LDM and so on the generalizing specialist will instead capture it in the most appropriate place(s). In this case that could be in the form of one or more acceptance tests as well as in the source code. In short, a generalizing specialist can choose the best artifact to to capture the information in one and one only place. The implication is that a team composed of generalizing specialists will be more effective than one composed of specialists.

  3. Improved flexibility. In his discussion of integrating usability specialists onto an agile team, Paul Hodgetts discusses several practices which result in productivity loss which are motivated by having specialists on your team. Specializations forces the team to pre-assign tasks to individuals, thereby hindering the team's ability to dynamically allocate tasks as new circumstances emerge.

  4. Less risk. Specialization drives teams to break down their iteration tasks to accommodate each person's specialty, resulting in finer-grained tasks and more points of hand-off between people. This can be seen in the diagram of Figure 2 where each specialist does their work, handing it off to the next specialist. The problem is that every time there is a hand-off between people there is information loss, documentation is the worst option for communicating information between people (see discussion about the CRUFT calculation), thereby increasing overall project risk. Figure 3 shows how an agile team would be organized -- instead of throwing artifacts "over the wall" to one another agile team members instead share the artifacts between them, working together to evolve the artifacts as needed and when needed, learning from each other as they do so. This lowers overall risk because there is less information, greater knowledge of the system amongst individual team members, and growing skills amongst team members.
  5. Fewer bottlenecks. Specialists become bottlenecks, reducing overall team efficiency, when work queues up for them. For example, a single database administrator (DBA) is assigned to support four development teams due to lack of database expertise amongst other people. This would be perfectly fine if the four teams generated less than one person's worth of data work in total, but in most organizations as soon as it was recognized that the DBA had slack time available to them they'd likely be assigned to one or more other teams until they finally had no more slack time available to them. So, because work load isn't consistent work will queue up for them sometimes, which means that the teams which they're supporting need to wait for them to get the work done, reducing overall team efficiency as a result. The specialist in effect becomes a bottleneck. Sadly, assigning experts to multiple teams is perceived by traditionalists as efficient because they look at it from the point of view of resource allocation instead of the point of view of overall team effectiveness.

Figure 2. A traditional software development team.

Figure 3. An agile software development team.

Generalizing Specialists and the Whole Team Practice

The Whole Team practice, popularized by Extreme Programming (XP), recommends that you include everyone on the team with the skills and perspectives required for the team to succeed. Furthermore, it recommends that everyone on an agile team contributes in any way that they can. If people are generalizing specialists then it becomes much easier to form whole teams because it will be easier to find someone with the skills that you need. If people are specialists then you'll find it much more difficult, and you'll often be forced to have a single person work on multiple teams because those teams need someone with their specialty.

What About Specializing Generalists?

Sure, why not? In this case someone starts as a generalist and then picks up one or more specialties. This would be just another path, albeit a rare one, to the same strategy.

Generalists vs. Generalizing Specialists

A generalizing specialist is more than just a generalist. A generalist is a jack-of-all-trades but a master of none, whereas a generalizing specialist is a jack-of-all-trades and master of a few. Big difference. A team of generalists can easily flounder because none of them have the skills to get things done. Similarly, a generalizing specialist is more than just a specialist. A specialist is narrowly focused on a single topic, making them very effective at that topic but not at others. Specialists will often be blind to the issues which other specialists focus on, and as a result will struggle to work with those other specialists effectively. As Figure 4 indicates, people who are generalizing specialists are in the "sweet spot" between the two extremes of being either just a specialist or just a generalist, enjoying the benefits of both but not suffering from their drawbacks.

Figure 4. Between the extremes.

Figure 5. Comparing various skill strategies.

Figure 5 compares people following different skilling strategies -- in this case I'm showing only four potential skills (S1 to S4) to make my point, but in the real world you would consider much more than just four. There are three important points that I hope to make with this diagram:
  1. Generalizing specialists are not just generalists. Time and again I've found that people confuse the concept of a generalizing specialist with that of a generalist, but as you can see a generalizing specialist has a much different skills profile than a generalist. Remember, a generalizing specialist has a general knowledge PLUS one or more specialties, whereas a generalist just has general knowledge.
  2. Generalizing specialists are typically not "super skilled". Although a generalizing specialist will eventually become more skilled than either someone who is just a specialist or just a generalist, that doesn't mean that they are an expert at everything. The IT industry changes too quickly so that someone can become expert at everything (regardless of what their ego may be subconsciously telling them) so it's clearly unrealistic to expect this of someone.
  3. Generalizing specialists are not just specialists. A specialist is someone who is narrowly focused in a single skill, although will likely have minimal skills in a few other domains as you see in Figure 5.

Is There Still Room For Some Specialists?

The quick answer is yes, depending on the context. There are two categories of situation where your team may find the need for specialists:

  1. Short-term unique activities. For example, your team may find that it needs to setup and configure a database server. Although you could figure it out yourselves, it's probably easier, faster, and less expensive if you could have someone with deep experience help your team for a few days to work with you to do so. This person could be a specialist in database administration. These one-off situations often occur at the beginning of a project or at the end of the project, what Disciplined Agile Delivery (DAD) would refer to as the Inception or Transition "phases" of your project.

  2. In scaling situations. At scale you may find that the complexities you're dealing with may require specialists focused on addressing those complexities in an ongoing manner throughout your project. The scaling factors called out in the Software Development Context Framework (SDCF) can help to make this a bit clearer. For example, your team may find itself in a situation with high technical complexity, which in turn makes your build so complex that you need someone(s) specifically focused on being "buildmeisters". In situations of domain complexity or organizational complexity you may bring one or more business analyst specialists onto the team to help you explore the problem space you're working in.

Bottom line is that it it isn't a black and white world and you will need specialists from time to time.


In many ways a generalizing specialist is simply a software craftsperson. The reason why I don't use the term "software craftsperson" is that it is a loaded one that is likely to turn off a large number of traditional developers that prefer something along the lines of "software engineer". I believe that generalizing specialist is more palatable.

In short, my experience is that generalizing specialists are much more effective than either specialists or generalists. The best developers are generalizing specialists, or at least actively are trying to become so. There is still room for specialists within your IT department, they can often act as internal consultants to your development teams, but as IT departments become more agile I suspect that we will see fewer specialists surviving over time.

Robert A. Heinlein said it best: "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."