I’ve been on a number of different team types in the software development space. Some teams performed better than others, but I have found that a generalist can aid a team in its work. The purpose of this post is not to prescribe one way to do something. But, to tell you of my experience of when I’ve seen things work well within an agile framework. Keep in mind that all teams are unique and just because I have found success one way, doesn’t necessarily mean that it is the only way to go.
However, there are a couple of guiding principles that you may want to consider in your work. Also, keep in mind that these guiding principles don’t just apply to the software development space. One of the things about being an agilist is that you apply the principles to other aspects of your life. One of the reasons why businesses are focusing on agility, even when they aren’t a “tech company” is because the agility is a key to delivering value.
Overview of our work environment
The first thing to understand is that as your work becomes more abstract, you need to be able to make connections and conclusions without having concrete evidence. Just because you pull on lever “a”, doesn’t mean that you will get outcome “b” when it comes to business. I would argue, as David Epstein argues in his book Range, that our world today is more abstract than ever. The reason for this is that the paradigm shifted from making a thing to delivering value. Since value is an abstract concept that changes over time, a company focused on value constantly needs to change its approach in multiple avenues so that they can continue deliver value.
Apple, as an example, went from making desktops to an array of devices that delivered value. One big shift came in the late 90’s when it released the iPod. This gave a tremendous value to customers even though it wasn’t the first or cheapest option available. However, the value of Apple’s customers changed over time to where the iPod was no longer valuable. Apple continued to innovate and deliver value by transitioning off the iPod to their iPhone lines. The key thing to this, is that Apple had to make decisions based on the abstract business environment in which it operates.
Just as Apple had to pull multiple levers to capture market share and deliver value, so to must we figure out the abstract world in which we work. We operate in an environment where certainties are few, change is constant, and feedback isn’t necessarily complete. Because of that environment, generalization can help draw conclusions from a variety of experiences to deliver value.
What is a Generalist?
Generalization does not mean you know a little about a lot of different things. It is more than just having a surface knowledge in a various fields. Generalization means that you have a proficiency in multiple domains. Now, proficiency doesn’t equate to expertise, but you know enough about the standards and best practices to solve a problem. Because of this proficiency, you are able to apply principles and ideas from one domain to another. This ability to cross pollinate makes innovation more likely to happen.
How Does generalization work on teams?
When it comes to producing value quickly on a team, generalization can help cover a lot of knowledge ground that may be needed to provide solutions. Because you are working in a complex environment, where how you are going to solve a problem may not be outlined, generalists can create the conclusions and abstractions necessary to formulate a solution. Additionally, a generalist can perform multiple functions on a team that may increase your team’s productivity.
As an example, the most agile team I worked with had a couple of core generalists on a team. When problems came up, we didn’t have to match schedules with other specialists outside the team to craft solutions. The core competence was already there. We just had to apply that knowledge to a new problem to craft an effective solution. We were able to move quickly and get to work building a solution of value for our client.
That experience, being able to rely on competent generalists, falls inline with how Scrum Guide defines a team. Per the Scrum Guide, a team should have all the tools and knowledge necessary to accomplish a task (or build a product increment). With the team composed of a few generalists, we experienced what agility really looks like in a real-world application.
The Law of Small Teams
Now, you may be able to replicate my experience with a team of specialists. And that approach is fine too. The key thing to remember is that you need to follow one essential law of business agility as outlined here by Steve Denning. In Denning’s work, he defines three core laws that create business agility, one of which is the law of small teams. There is no mystery to this law. It essentially states that a company wanting to enhance their agility needs to have small teams that are cross-functional, autonomous, and have a high amount of interaction and collaboration.
If you have a team that consists solely of specialists, you are highly likely breaking the law of small teams. Let’s look at each characteristic in detail with a team of specialists.
Cross-Functional
A team needs to have all the skills and ability needed to produce a product increment, while still being small. In cases of a solely-specialized team, you may not have a small team. If you were to break out major pieces of work to produce a product increment, your team would consist of an Architect, Developer, Quality Assurance Engineer, UI/UX design specialist, BA, and Release Engineer. Each member of the team has their specialization to carry a problem through to a solution. That’s a team of six people to develop something of value. Does it follow a small team size? I guess. Is it cross functional? Sure. Does it subject yourself to a high amount of risk? Also, yes. Here’s how:
Delivering a product increment needs to have all six members present to get something done. What happens when one of the team members are out for a period of time? A bottleneck in the process is created. If all you have is specialists, then no one can tend to the domain of another person.
An additional consideration that must be made for a team of specialists is how much work is being fed to individual members of a team. Not all problems require the full time attention of a UI/UX developer. In some cases, once the standards are set for that solution, developers can use those standards to solve future problems. Additionally, if a schema is established and a framework outlined, what additional input is an architect or DBA providing? If those roles on your team are highly specialized, they may not have enough work from iteration to iteration. Thus, along with risk, you are introducing waste as well.
Autonomous
Just as a team needs to have all the abilities to make a product increment, a team also needs to be able to make their own decisions as to how they are going to formulate that increment. In a team of specialists, no one has the ability to abstract their knowledge to come to a definitive solution outside of their area of specialization. They can only speak to their own domain expertise.
Some decisions require a synthesis of knowledge from various domains to come to the right conclusion. A generalist is more likely to be able to draw those conclusions with little feedback or without all the right information beforehand. A group of specialists may be able to abstract between everyone to get to a proper decision, but this will only come after much debate and no-one will be fully confident in the decision. So, to a degree, the confidence that occurs within an autonomous team is lacking with a group of specialists.
Collaboration
In the earlier example of a team of specialists, we looked at having 6 different people on the development team playing their specified role. On a team with some core generalists, you may have a development team of 3 or 4 people. Now, logistically speaking, which team size is easier to coordinate and collaborate? The fewer people in place, the less friction when it comes to collaboration. Additionally, while a group of specialists sounds great, in practice they are never fully dedicated (to mitigate the waste issue outlined before). Thus, in order to collaborate with specialists, you need to compete for their time with other teams or priorities that are taking their time.
Individual expertise visualized
Now, it may help to visualize what a generalists looks like in terms of expertise and domain knowledge. Various texts and papers refer to a generalist as a “T-shaped” person where as a specialist is an “I-shaped” person. The top part of the “T” represents breadth of knowledge and the lower vertical part of the “T” represents depth of knowledge. But, when it comes to explaining some people’s ability, the generalization is inadequate. Some of the most agile developers I know where more than just a “T” shape. These people had depth in multiple subjects in addition to deep breadth of knowledge. One term that I’ve heard to these type of skilled individuals is that of a fork where each tine represents deep understanding of a domain.
Specialists
Taking the cutlery analogy further, I’ve found that one way to visualize breadth and depth of knowledge with specific utensils. The specialist is that of a knife there focus is narrow, depth is deep. But there isn’t breadth into other subjects. Another type of person is more like a spoon. Like the specialists, they have focus and depth in one domain. However, within that domain, they’ve enlarged their boundaries and pushed things farther in that domain than others. They’ve experimented and enlarged their knowledge within that domain, but haven’t branched out to other domains. These individuals are a subset of specialists and are typically a bridge between the specialists and generalists. Given more time, they’s eventually make the move to a generalists.
Generalists
The final type of person is the generalist. This person is best represented as a fork. As stated earlier, each tine represents a deep knowledge of a particular domain. However, unlike the specialists, they’ve gained a lot of breadth. When you look at the fork, there is a significant base between the handle and the tines. This would represent the amount of knowledge a generalist gains through various experiences and work. Their breadth isn’t superficial. It isn’t that they know a little about a lot, but they know a lot about various subjects. With that deep foundation, they then build upon that depth to create a deep knowledge of many domains, not just one.
The take away
Teams can move quicker, be smaller, when there are a few generalists in it. Is there anything wrong with being a specialist? No. But, if you haven’t found your fit, and have interests in a lot of different subjects, continue to explore. You’re on your way to being the generalist needed on your team. Over time, you’ll find various domains where you can dive in and get more depth.
So, sample, try new things, gain more experience in a lot of different things. The experience will only serve you better later. If you want more information, I recommend reading Epstein’s book Range or at least look into what he is talking about. Specialization gets a lot of play and attention, but more research is coming out for those that are on the generalist’s path. I’ve seen how effective generalists are on agile teams. It is something worth working toward, if that is the path that fits you.
