T-model: UX Generalist vs. Specialist

In a discussion I was having with a potential client yesterday the topic of UX generalist vs. specialist came up. I believe guerrilla versions of UX fields can be taught to specialists in order to become T-shaped UX practitioners, the good kind of generalists.

The potential client requested EzGov's help and estimated that he would need "1 UI lead and 3 UI designers for 6 months". Excellent, because that means a serious amount of work. The trouble is, none of our team members have a business card that says UI Designer.
The set of activities required ranged from "gathering requirements", through "expanding visual design guidelines" and "preparing and managing usability tests" to "creating HTML prototypes". We quickly identified 3 to 4 EzGov job titles that together covered all the skills requested: information architect, visual designer, producer and probably system analyst too. At EzGov we are specialists, not generalists. Now, is this a problem?

The client may see this as a problem: If he hires 4 UX team members he needs to first understand the specialisms and then decide what to ask from whom. Also, with more specialists more handover activities are required, introducing room for error and delays. Finally, instead of the exact 4 members for 6 months he might see 6, 7 or 8 people walk in and out of the project, each requiring some degree of ramping up and assistance in e.g. getting to know the people, getting access to project documents or even getting access to the building.

Of course we will reply with the argument that the people will be there only when they are needed improving their efficiency, and of course he is getting trained specialists, drastically improving the quality of the work. Also, since we are used to working together as a team, our handovers will be smooth.

I would say that there are two ways to look at generalists: The negative way is to say that a generalist is equally bad at everything and there is nothing he can do really good: he is shallow all the way. This could be said from someone who has at best has read a series of introductory books in our area and has designed and developed a small number of say, websites.
The positive way is to say that a generalist has broadened his horizon from initial deep knowledge in one area, gained through training and experience. This could be a formally trained visual designer who was given the chance to develop information architectures for interactive web applications under the guidance of an information architect mentor.

When I applied Jakob Nielsen's definition of guerrilla usability to information architecture (in A piece of IA pie) I must confess that I had the negative view of shallow generalists in mind. But of course Guerrilla IA can be taught to specialists in other areas, aiming to create T-shaped UX practitioners. That is what we have been doing with our visual designers, producers and system analysts too. That, plus mentoring, reviewing each other's work, lunch & learn sessions, and more, but teaching guerilla IA tactics helped.

In the end, what turned out to be really helpful to the client was the fact that we had documented our process and deliverables, and that in the introductory meeting I could show the client a clear overview of our way of working: at EzGov we have spent the last two years identifying and documenting user experience deliverables as well as the skills required to create them. The members of my UX team have different backgrounds and each contributed to the whole. And even though we have documented these deliverables in considerable detail, collected examples and created templates for everyone to use, we each have our specialty area but can function as practitioner in the other areas too. We are all T-shaped UX pratitioners.