Comments on: Why Projects Don’t Need Specialists

By: Rick

Rick — Mon, 11 May 2009 21:13:40 +0000

I’m a little late discovering this post, but I just wanted to drop my 2 cents, being more or less a specialist:

In my opinion, the primary role of a specialist on a team is to inform, educate, guide and coach, *not* to execute (at least not exclusively in his/her field of specialization). That is the main contribution a specialist makes. And if he/she does it well, none of those objections apply. As far as the actually work goes, the specialist is just one of the team members.

Specialization is a precious commodity in a field where it takes many years to fully master something. The problems mentioned are not caused by specialization, but bad management and the wrong attitude of many specialists, often worsened by the attitude of the other team members (“let the specialist deal with that stuff”).

Simply thinking you can solve the problem by doing away with specialists is cheap management BS. Managing techies is hard, lowering your standards is not a solution.

(And yes, many so called specialists do simply dig themselves into a very narrow field, and have no place on an Agile team. But recognizing the difference between real, useful specialists and people with tunnel vision is also a required management skill.)

By: Jason

Jason — Thu, 15 Jan 2009 19:16:05 +0000

I find it funny that people are so negative about this. They seem to think that being a generalist somehow makes you less capable than a specialist.

It doesn’t.

The point is to break down the barriers between the jobs assigned to your team. In agile development, the problem is instantly visible – a 1 week delay in a 1 month cycle is instantly visible to everyone interested in the project!

Developers, it’s time to move up the food chain. Learn more than one area and you’ll be more useful to the team, more employable in the long term, and better able to interact with everyone else. Pair up with someone who is working on something you’re not familiar with.

By: Process Control Guru

Process Control Guru — Sun, 11 Jan 2009 02:01:47 +0000

There’s an old saying:
A specialist is someone who learns more and more about less and less until, eventually, they know everything about nothing.

A manager (or generalist) is someone who knows more and more about less and less until, eventually, they know nothing about everything.

In my 25 years of experience, alternating between generalist and specialist roles, I have always tried to expand my breadth in topics outside my core expertise, while maintaining depth in a few specific topics.

The real trick, when you are in a generalist (management) role, is to be able to quickly learn enough from the specialists, so that you can make good decisions. In other words, you become a specialist on-demand.

The trick, when you are in a specialist role, is to be able to look at the world through the eyes of others. It’s a delicate balance. Of course, you need to speak for your specialty, but you also need to expand your horizons.

The world will always need people in both specialist and generalist roles. It has been said that up until the 1700’s, it was possible for a single individual to have expert knowledge in every field of study. Today, however, the base of knowledge is doubling roughly every eighteen years. We will need to continue to adapt to this environment: learn new technologies, know when to draw on the experts, and most importantly, actively manage your own skill development. Be sure to actively choose your desired fields of expertise.

For those who are interested in the specialty of process control, visit my blog, at http://processcontrolguru.wordpress.com

By: Hiring Technical People » Hiring for an Agile Team: Possible Questions

Hiring Technical People » Hiring for an Agile Team: Possible Questions — Thu, 01 Jan 2009 15:56:40 +0000

[...] This question partially answers some of the commenters in Why Projects Don’t Need Specialists. [...]

By: Kenneth P. Katz

Kenneth P. Katz — Tue, 30 Dec 2008 03:47:07 +0000

I usually agree with Johanna but not this time. It is a fact of life that people have different interests, skills and talents. We are doing complicated things and it is a completely unreasonable to expect people to have the full range of talents needed. Adam Smith talked about the division of labor more than two centuries ago and it is still valid today.

Furthermore, as project managers we often have to work with what we are given, which is not always the top talent but whomever is available — which is to say people who at most are good at one thing. That’s reality, and wishing that reality away is inexcusable.

By: Thierry Thelliez

Thierry Thelliez — Mon, 29 Dec 2008 21:51:06 +0000

It depends so much on the project context. How is the product complexity managed?

Is a specialist necessary to reach a competitive value proposition for the business (large db, media streaming, fast transactions…)? In this case this is perfectly justified, you need the specialist even if this creates bottlenecks.

Or are specialists needed to cope with an unnecessary complexity, obscure code, poor tech choices (e.g. jumping on a technology just because…)? Specialists can also be guilty of contributing to the complexity for job security.

Unfortunately I see too many cases of the later.

By: Jim Ward

Jim Ward — Wed, 24 Dec 2008 17:12:06 +0000

Johanna, as usual you are right on target. Specialization creates bottlenecks and inefficiencies. Most people who work on projects can’t think of a better way. Specialization leads to multi-project assignments, the task splitting or context switching that you have rightly railed against in the past. Management wants to utilize all of its personnel resources all of the time, optimizing the wrong variables. While specialization is not completely avoidable in dealing with highly technical skills, the nature of project work will require that not all specialists are fully utilized all of the time. We should be optimizing project velocity, not personnel usage. Eli Goldratt wrote very well about this over 20 years ago, as have many others, including yourself and yours truly.

By: Joakim Karlsson

Joakim Karlsson — Wed, 24 Dec 2008 10:51:06 +0000

You’ll always have specialists on your projects. Individuals will always have different interests and capabilities.

Having specialists on a project is not the problem. It’s how you use them.

If your DB-savvy person is the only one who is allowed to touch the database schema, you’re probably in trouble.

If, instead, you use that same person to lead others in database related work when that’s the bottleneck, you’re probably better off.

By: JohnC

JohnC — Tue, 23 Dec 2008 15:36:33 +0000

I read this and just could not believe it.. I guess I will always have a job trying to make databases created by developers with no concept of performance and tuning work once it is loaded with real data. Sure they say, “He’s just a specialist with hurt feelings.” Not at all I am someone who realizes that it takes years of experience to learn the what, why and how of how to design, create and tune a database structure… This whole premise of the post is un relalistic.. I guess on my next agile project I will ask to replace one of the .NET developers since I understand the idea of programming.. Let’s get into the real world here people.. LOL

By: Dwayne Phillips

Dwayne Phillips — Tue, 23 Dec 2008 14:05:41 +0000

I like having specialists around, but as you note, you cannot have them be a bottleneck on a project. If the specialist isn’t here today, the entire project stops and waits for their return. Once again, think about what you are doing. There are plus and minus to these things and traps.