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
- Why generalizing specialists?
- Compariing generalizing specialists with other skilling strategies
- Becoming a generalizing specialist
- Generalizing specialists and the whole team practice
- What about specializing generalists?
- Is there still room for some specialists?
- Why not use the term "T-Skilled"?
- Related Resources
1. Generalizing Specialist: A Definition
In software development, a generalizing specialist is someone who:
- Has one or more specialized skills (e.g. User interface design, Project Management, Security
Engineering, Marketing, ...).
- Has at least a general knowledge of software development.
- Has at least a general knowledge of the business domain in which they work.
- 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,
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:
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.
- 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
- 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
- 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
- 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
- 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.
- 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:
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".
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
way of working (WoW) tailoring
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
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:
- 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".
- 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.
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
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