Generalists versus Specialists in Agile

Generalists versus specialists — it is an ongoing debate. Is it better with generalist or specialist team members in agile software development or elsewhere?

[bibshow file=http://www.citeulike.org/bibtex/user/greger/]
Having a “whole multidisciplinary team with one goal” is one of the top ten key agile practices [bibcite key=”citeulike:12799124″]. Teams of heterogenous specialists have inherent communication and collaboration problems. A strategy is needed to take full advantage of a heterogenous team [bibcite key=”citeulike:12883725,citeulike:12010180″].

Generalists versus Specialists — Is that the Solution?

I like to think of myself as a generalist rather than a specialist. Could adding someone like me to each team help solve the problems of diversity and heterogenity and transform them to success factors? Perhaps a team of specialists can act as a single meta-generalist? [bibcite key=”citeulike:12883878″] Reuven Gorsht of SAP recently suggested in Forbes that indeed having more generalists in the workplace would be required in the future. The generalist or specialist debate has been going on for ages. In medicine, clear benefits of generalists have been found [bibcite key=”citeulike:12883843″]

Gorsht lists a number of characteristics of successful generalists. Here they are in headline form together with my comments.

• A “can do” attitude. Or as my colleague puts it: “I’m a consultant, just tell me the topic and I’m an expert tomorrow.”
• Extreme curiosity. Learns new topics in hours. If it is true that our own sense of ignorance, of knowledge deprivation, fuels our curiosity [bibcite key=”citeulike:12883744″] then nurturing that sense of deprivation is a shortcut to extreme curiosity. What better way to discover the limits of our knowledge than to “join the conversation”.
• Connects the dots. Or as I would put it, connects the boxes. The boxes where the specialists sit more or less isolated from each other.
• Empathic. Having the ability to see the world from other people’s perspective. This would be especially useful in dealing with a team of specialists I guess. On the other hand, empathy can be trained [bibcite key=”citeulike:12883737″] and the situation can be modified to better enable it [bibcite key=”citeulike:12883740″].
• Leads by influence and collaboration. A non-threatening style is required to enable others to learn and flourish. [bibcite key=”citeulike:6565152″]
• Challenges the status quo and encourages new ways of doing things.

As a consultant, I live by these values and they are exactly what I bring to the customer. Does that mean that organizations should have “consultants” (or generalists) on staff instead of getting outside consultants when they are needed? (By consultants, I don’t mean “bread and butter” or “resource” consultants.) No, most organizations probably do not need to have generalists on staff. Having them on call should be enough. By the way, while Gorsht makes a strong argument for why there should be generalists in an organization, he doesn’t really describe how they would be integrated in the organization. Generalists are rare, and being a generalist is not always beneficial to your career. [bibcite key=”citeulike:12883881″]

Conclusion

While a generalist may be a force of nature when it comes to these values, there are many things you can do today to make your teams bolder, more curious, more empathic and more ready for change. Many of those things that can be done are not about recruiting, selecting and training employees. It is about how you build your organization. Is there a culture of trust? Are failures allowed? Is there time for empathy? Are there opportunities to discover knowledge gaps? In the field of medicine, it has been shown that institutional factors play a much bigger role than individual factors in students selecting a generalist career [bibcite key=”citeulike:12883848″]. My conclusion in the generalists versus specialists debate is that while you need both, encouraging “generalism” in your specialists is a good first step.

References

[/bibshow]