Johanna’s post, projects don’t need specialists (and the 19 the comments that went with it), got me thinking.
People tend to coalesce around shared interests–both in terms of what they find interesting, and what concerns them. Take the category of retired people. It’s not a particularly strong category, they may have overlapping pursuits, but have a stronger set of shared concerns, such as access to health care, social security, etc.
Professional concentrations are no different.
People who specialize in data modeling are concerned about having a rational and coherent abstraction of the data in the domain.
People who specialize in process control focus on real-time issues.
People who specialize in data bases are concerned about tuning and performance.
I could go on with lots of other professional categories.
All of these are legitimate concerns.
Here’s where it gets sticky. When you have a project with a lot of specialists, each has a particular (legitimate) point of view and (legitimate) set of concerns. If they haven’t had experience working in other technical areas they may not consider other concerns.
Labels, titles, and functional silos reinforce categories and create an echo chamber for concerns.
So if you have a project with many specialists, you end up with lots of politics as people seek ascendancy for their particular concerns. If the specialists are acting as vendors to a project team, those specialists may not be invested in the delivery goal of the project, only in delivering their part answering their concerns.
That doesn’t mean that people are bad and wrong, just acting the way people act when the coalesce around categories.
It’s not that projects don’t need specialized knowledge; they certainly do. But they need people who can perform specialized technical tasks and understand that there are multiple sets of technical interests involved, all of which must be, at some point, softened to the project delivery goal.
Handling the need for specialized skills isn’t only a matter of scheduling constraints. It’s a matter of conflicting concerns and politics.
I am in favor of specializing generalists, or generalizing specialists–people who can perform specialized tasks (as well as make a contribution outside their speciality–and see other technical concerns and focus on a project delivery goal rather than one set of concerns.
Reducing categories (having “developers” rather than many named specialists) reduces differences and helps people focus on shared goals.
