Cross-functional teams are a darling of contemporary agile rhetoric. It’s important to note that cross-functional can mean at least two different things. The more pedestrian reading is that the team comprises all talent necessary to do its work. The more radical interpretation discounts specialization and holds that any team member can rise to any task germane to the goal. This latter perspective was popularized in Extreme Programming’s marginalizing of domain expertise. It lives on in Scrum courses where trainers admonish people that everyone should be a tester. If the only remaining work is testing, you will do testing. Part of being a team member is doing what needs to be done.
Malcolm Gladwell’s Outliers suggest that 10,000 hours of practice precede mastery. Agile folks often tell us that you can practice your way to cross-functionality. However, most people miss that Gladwell ascribes the roots of greatness more to social context than to will. Ericsson’s original 10,000-hour claim (The Making of an Expert, Ericsson et al., Harvard Business Review, July-August 2007) views intentional practice more as a precondition for success than as a means to success.
I think there is more than a grain of truth to the 10,000-hour argument, as discussed previously in Practice Makes Perfect. It’s healthy for Java programmers to grok UX tools, and vice versa. Teamwork is about shared knowledge and communication. Effective communication begs high context. Head knowledge provides some context but there’s no teacher like experience. Even Java programmers can intuit what a good interface looks like after building hundreds of them instead of just mechanically creating them using GOMs analysis and Fitt’s Law.
Behind the second form of “cross-functional” looms the spectre of a commoditized work force. You can assume plug-compatible employees for light unskilled labor. Programming is becoming a more common skill and, perhaps eventually, it will become natural to hire teams comprising members with adequate and relatively undifferentiated programming skill sets. Programming may become unskilled labor.
None of the 10,000-hour pundits ignore the importance of individual talent. Talent is of small importance in unskilled labor but it is everything in the arts. Even though the 10,000 hour number is commonly used to quantify the German nightclub practice that prepared the Beatles for stardom, no amount of practice is enough for some people to become opera stars. Not everyone can become a Rembrandt or, to shift disciplines, a Usain Bolt. Epstein’s The Sports Gene (Current Hardcover, 2013) dispels the 10,000-hour myth with genetics. This brings us onto dangerous ground: is it racist to say that Nigerians are naturally better runners? Is it sexist to say that women—another genetic consideration, right?—are naturally better computer scientists? (Read You Go, Girl! before answering too quickly.)
This begs the central question: is software product design purely a matter of science and manual labor, or is it an art? I’ve been corresponding with Peter Denning about the innovation process, and he’s convinced me that there are people who can design and some who just can’t. It’s the same with many other software product skills.
Talent matters in the application of many software disciplines. The first definition of “cross-functional” is still crucial: complex products draw on many disciplines, and most programs are complex products. Rather than trying to become an expert in all of your weak areas, practice them enough to be a good team contributor. However, focus on improving what you’re good at. And, of course, try many things: it may take a while to find your true calling.