Esther's Insights re Specialists and Generalists

Esther has insights, Specialists AND Generalists, on Why Projects Don't Need Specialists. Her point, that people tend to coalesce around their interests, and that as specialists, they may not share interests, is something I have also seen on projects. As Esther says,

Reducing categories (having “developers” rather than many named specialists) reduces differences and helps people focus on shared goals.

Shared goals that lead to working product is the point of the project.

P.S. I realized late that I had forgotten to title this post. Fixed.

6 thoughts on “Esther's Insights re Specialists and Generalists”

  1. For me it depends on a project. If the project is standard, the one you’ve done before a few times I’d share the approach.

    However sometimes you deal with projects which requires very specific knowledge or experience. Most of R&D projects fall into that category. Then, you need to find specific specialist instead of plain developers. E.g. for one of my last project it took a developer experienced in programming telecommunication protocols, a project coordinator with vast telco knowledge and a C++ guru. Exchanging those with just a PM and a couple of developers wouldn’t be a very good idea. We’d fail.

  2. I think that most people are not understanding the point of this discussion. Specialization creates bottlenecks, conflicts across projects and personnel utilization issues (trying to optimize the wrong variables). We need to recognize that we pay a price for this, and incorporate the price into our project planning, coordination and management. Generalization is a way, maybe the best way but not the only way, to reduce that price. Building in idle time for highly specialized personnel so that we can assure that they are available when we need them on projects is another way, but that seems to be an anathema to managers, particularly in functional or matrix organizations.

  3. Pawal –

    I guess I wasn’t clear.

    I am not suggesting that you try to do a project with people who don’t have the necessary skills. Of course you’d fail.

    I am suggesting that the we reduce the specificity of organizational categories, and look for people who understand interests and concerns outside their own specialization.

  4. Johanna,

    On the general level I agree – if that’s suitable we try to have generic roles in our teams. However there are projects where specialists are valued over generalists.

    Yes, it’s all about necessary skills, but when you need someone with vast knowledge in specific area you look more for a specialist than a generalist who can suit in broader range of situation but his expertise is limited.

    Of course you can name all people who produce code “developers” but it doesn’t actually change how others look at them.

    Or maybe I just get this whole generalist vs specialist thing wrong and it’s more about labels we pin on people rather than about their skills.

  5. Hi, Pawel –

    The labels we pin on the people, and the organizational silos we create around functions and specialties have enormous power.

    We do need people with special skills; though my preference is to hire people who along with a special skill have adequate skill in broader arena.

  6. When a project is initiated, a project team is formed, or at least should be. On the best run projects, the team does what needs to be done in order to make the project succeed. Specialists may often take an attitude of “That’s not my job” when confronted with the needs of the project. This is completely understandable when one is asked to provide specialized skills on a limited basis to several projects simultaneously.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: