Thursday, November 29, 2007

Specialization vs. Generalization

Have you ever seen Gordon Ramsey in action?  Not on his Fox Network show, but on his original show, Ramsey's Kitchen Nightmare?  (The Fox Network version is staged and edited to be as confrontational as possible.)  He tries to help a restaurant that is on the verge of closing down and does his best to change things around in a week.  To be honest, there's not a lot that can be done in a week, so if the basics aren't there then there is going to be trouble.

One of the key things that he stresses, however, is to keep the menu simple and to specialize in something.  In some respects this goes completely against the grain of what students are being taught in school and what our supervisors are busy telling us.  IT people are thought of as being replaceable cogs in "the machine", not to specialize, but to be replaceable.  To be honest, IT staff foster this perception as it makes it easier to sell their services internally within an organization and to external organizations, if they so wish.

In a previous life, when I worked for a "large, multinational consulting firm" it was not considered a good thing to be different than everyone else.  Because the types of problems faced by a large consulting firm are quite varied, having a large pool of generalists made it easy for the company to assign people to a project, after all, it's just a different type of nail and they have a lot of hammers (Bernard Baruch).  The more hammers they had the easier it was to sell services to a client.  If a special hammer was needed there was usually a small group (less than 1,500 people in a 65,000 person organization) who had more specialized skills and could be brought in (at a premium of course) to assist the project.

Is this the right way to do it?  Should most people be generalists with a few specialists who could be parachuted in when needed?

Personally, I believe this depends on the aspirations of the people you are dealing with.  In the consulting firm mentioned previously, the vast (90%+) majority of the people were on the fast track to management:  "up or out".  This meant that their time as a developer/designer was limited and that there was no need/desire to become proficient in one particular area of expertise, unless it was a business area.  For these individuals the generalist appellation is more than sufficient.  Some people, however, like the technology.  They like being able to make the computer do their bidding. This group of people is more likely to follow a more specialist perspective and become "experts" in this area.

Before labeling someone either a generalist or a specialist, find out what their aspirations are, then, when assigning new work, take these factors into account when determining who works on which project.  In some cases it may make more sense to assign a less experienced specialist to a project than a more experienced generalist as the final solution may be more effective at resolving the clients issues and isn't that what it's all about?

No comments: