Generalizing Specialists: Improving Your Effectiveness

1. Generalizing specialist: A definition
2. Why generalizing specialists?
3. Comparing generalizing specialists with other skilling strategies
4. Becoming a generalizing specialist
5. Generalizing specialists and the whole team practice
6. What about specializing generalists?
7. Is there still room for some specialists?
8. Why not use the term “T-Skilled”?
9. Conclusion
10. Related Resources

1. Generalizing Specialist: A Definition

In software development, a generalizing specialist is someone who:

1. Has one or more specialized skills (e.g. User interface design, Project Management, Security Engineering, Marketing, …).
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.

The concept of being a generalizing specialist is applicable outside of the software domain. However, the focus of this article will be on software.

As Figure 1 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 1. Between the extremes.

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

2. Why Generalizing Specialists?

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.

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 specifications then those specifications 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 software teams 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 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. 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 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.
4. Fewer bottlenecks. Specialists become bottlenecks, reducing overall team efficiency, when work queues up for them. For example, a single data engineer 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 data engineer 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.

3. Comparing Generalizing Specialists and Other Skilling Strategies

Let’s start with the main points. As you see in Figure 2:

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 a generalizing specialist is more than just a generalist. A generalizing specialist,on the other hand, is a jack-of-all-trades and master of a few, as you see in Figure 2. A generalist is a jack-of-all-trades but a master of none, as you see in Figure 3. Big difference. A team of generalists can easily flounder because none of them have the skills to get things done.
2. Generalizing specialists are not just specialists. Similarly, a generalizing specialist is more than just a specialist. A specialist is narrowly focused on a single skill, as you see in Figure 4, making them very effective at that skill 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.
3. Generalizing specialists are typically not “super skilled” either. A common mistake is to assume that generalizing specialists have to be great at every skill. No, as Figure 3 shows they are good at one or more things and have broad knowledge of a range of skills. This isn’t the “super skilled” person of Figure 5, although in a few cases people like this do exist. But that is very rare in practice. Granted, 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 business environment 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.

Figure 2. The skills of a generalizing specialist.

Figure 3. The skills of a generalist.

Figure 4. The skills of a specialist.

Figure 5. The skills of someone who is “super skilled”.

4. Becoming a Generalizing Specialist

When you get your first job it is often in a junior role. 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 your profession, in related professions of people that you regularly interact with, and in your relevant business domain. When you do this you evolve from being a specialist to being a generalizing specialist.

Figure 6 depicts a fictional skills assessment for someone, showing how it evolves over time. In this example, the person has solid skills in skill #5, and some initial knowledge of other skills. Then, a year later, they’ve improved all of their skills, including their picking up some knowledge of skill #3. They may have achieved this through training and education, mentoring, or non-solo work techniques such as modeling with others or pairing. Then, two years later their skills have improved further, although it’s interesting to note that focus on learning new skills may have motivated the person to let skill #5 go stale for now. It’s incredibly rare for someone to become “super skilled” at everything, although it is quite common for a generalizing specialist to become more skilled at a few things that interest them as well as have general knowledge of a wide range of skills. In short, generalizing specialist tends to be about being multi-skilled, not just “T-skilled” where you’re good at one thing and knowledgeable about many others.

Figure 6. How a generalizing specialist’s skills may evolve over time.

5. Generalizing Specialists and the Whole Team Practice

The Whole Team practice, first popularized by Extreme Programming (XP) and later adopted by most agile methods and frameworks, 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.

6. 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, to the same strategy.

7. 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 help addressing a security issue. Although you could figure it out yourselves, it’s probably easier, faster, and less expensive if you could have someone with deep security experience help your team for a few days to work with you to do so. This person could very likely be be a specialist. These one-off situations often occur at the beginning or end of an initiative, what Disciplined Agile (DA) would refer to as the Inception or Transition “phases”.
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 initiative. The way of working (WoW) tailoring factors can help to make this a bit clearer. For example, your team may find itself in a situation with high solution 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.

8. Why not use the term “T-Skilled”?

Although T-skilled is a great term on the surface, when you take a moment to think it through you soon start to see that it isn’t correct. There are two primary reasons why “T-skilled” isn’t the right term:

1. T-skilled is great in theory, but observably not true in practice. To see what I mean, consider Figure 2. That’s clearly not a T. Very few people, if any, have deep skills in a single area and then general skills everywhere else. They have varying levels of skills in a range of areas, sometimes very deep skills in a few areas. A more accurate term would be “comb shaped”, but that just doesn’t sound as cool as “T-shaped”.
2. T-skilled says nothing of the journey. As a term, T-skilled tries to describe the destination, which is fine. “Generalizing specialist”, or “specializing generalist” in a few cases, captures the idea of the journey that you’re on. As in many other aspects of life, it really is the journey that’s the important thing, not the destination.

9. Conclusion

In many ways a generalizing specialist is simply a craftsperson. The reason why I don’t use the term craftsperson is that it is a loaded one that is likely to turn off a large number of existing professionals. I believe that generalizing specialist is more palatable, giving a nod to the existing terms of generalist and specialist.

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

10. Related Resources

• Johnston, D. L. (1978). Scientists Become Managers-The “T”-Shaped Man. IEEE Engineering Management Review, 6(3), 67-68. doi:10.1109/emr.1978.4306682
• T-Shaped Skills (Wikipedia)