Why Projects Don't Need Specialists

I taught several PM workshops last week in Israel. The Israeli project managers have the same concerns that my US students do–it’s difficult to imagine moving to Agile or even just integrating agile methods into your project if you have specialists.

Specialists increase project delays in these ways:

They aren’t available when you need them. Because they are specialists, it’s too easy for the specialist to be busy on another task when you need that specific person. And, because you or the specialist estimate only the time the specialist needed, if you ask anyone else to do the task, the task will take too long.

The work backs up. No, you don’t need a specialist all the time. But when you do, you need them. So, since work doesn’t arrive as an even distribution, but instead arrives more in a Poisson distribution, the specialist has some periods of time when they aren’t busy, and more times when they have a queue of work.

Murphy’s Law will happen. Just when you need a specialist, that person will want a vacation, or want to get married, or go skiing for two weeks, or have a baby. Or, leave the organization.

PMs (and projects) don’t need specialists. They need people who are multi-talented and can finish tasks. Am I saying that we turn GUI designers into kernel developers? No, but there are many more things that a GUI designer or a kernel developer can do, rather than just one specialty.

If you have specialists now, rethink your staffing, and offer people opportunities to learn new skills. Your projects will progress faster and you’ll be more effective.

How about turning the specialists into special-area reviewers. “If you need to make a database change, its needs to be approved by Ms. X, our data guru.” “The communications protocols need to be approved by Mr. Y, who has responsibility for making sure protocols are consistent across products and releases.”

This might seem to increase the work for all involved (now as the regular engineer I have to get my work passed a myriad of reviewers), but avoids the specialist-work-back-up and it increases transfer of knowledge and best practices throughout the organization.

This is only a problem if the specialist is constraining work on a path with minimal lag. So, identify the areas of speciality that are a constraint on the low lag time paths. Creating generalists who can fulfill other tasks and perform in the specialized area is a great way to increase capacity at the constraint. Then you should subordinate the rate of work to the rate that it can be performed at the specialist area.

From a governance standpoint, this is why Agile is difficult and EVM is troubling. You appear to making progress at a rate sufficient to keep the project schedule promise (SPI is 1 or greater), but you have a hidden constraint in the system. We have to know where that constraint is and manage it early. By understanding the complexities, and managing them, we can apply Agile concepts to our projects.

This is all wrapped into “communal code ownership”, which is one of the core Agile practices. The problem isn’t limited to specialists — it occurs any time you have a single point of failure in a pipeline.

I totally agree with your post. People need to be able to integrate new ideas and create things with these new ideas. Do we always need someone to hold our hand? I’m not against a little hand-holding, but not all the time.

You’re being far too vague in what you mean by specialist. Until you pin that down, I don’t think there’s much of an argument here.

Worst case, I think you’re guilty of wishful thinking. Highly skilled engineers who can get work done equally quickly on every facet of a complex project are usually kept in storage right next to the the unicorns, under the flying pigs.

I’m with James on this one. Even on an agile team, someone’s going to be faster working on the widget component – maybe because he was just in there working on something else, maybe because he just “gets” the complexities of that component more than everyone else. And when deadlines are tight (when aren’t deadlines tight?), team members will choose to do what they can do best or fastest, which just makes them better and faster at that task. Over time, the team self-selects specialists.

So in order to not have any specialists at all, you have to:
– avoid putting any specialists on the team (no DBA, no “kernel guy”, no “guy who’s really good with Java/C interop”, no QA type)
– build enough time into the schedule so that people can do things that they’re less good at, and then force them to choose those tasks instead of the things they’re good and fast at.

I think the second part is harder – done poorly it simply reeks of micromanagement. Done well… I’ve never seen it done well. The best I’ve seen is weak specialization – all the team members are good enough that they could do any task, even if they couldn’t do it quite as fast or quite as well as the self-chosen specialist.

There is the ideal world and the real world. In the real world it is often unrealistic to have a team full of experts who can master every layer of the architecture. If you are hacking up a website then maybe. If you are leveraging a robust architecture like SOA, you would be lucky to have one person that can master all layers of the architecture.

Many projects reach a point of needing some expertise that “broad generalists” don’t cover. What distinguishes teams here is how willing they are to take a short-term productivity hit by arranging to pair someone senior up with the expert for cross-training. Teams that take the long view tend to need experts less over time.

Dennis is correct! A very top concern for any project manager and the function managers in the matrix the PM is using, is to know where the constraint is, and to know where it might be given the variability inherent in the job of completing a project. The constraint needs to be managed and the project plan needs to be based around the throughput on the constraint and how variability affects it, and other things that can become the constraint.

It is this fact and how to deal with it appropriately that is the focus of my “Zen of Agile Management” class (often offered at Agile conferences) and was the main focus of my book.

Specialists are potential bottlenecks. This is not a bad thing. Specialists offer marginal utility (in economic terms), aka added value. We have specialists because they do difficult things better than generalists. Specialists are a fact of life. The project manager should learn how to manage bottlenecks, rather than insist that specialization is removed. Loss of value-adding specialists leads to mediocrity. Mediocrity means undifferentiated results. If this is the case, why do the project in the first place? Why not buy a COTS solution instead?

What puzzles me is how having specialists is seen as hindering you from moving to agile development. You’ll have the same problem (if it is a problem) with any methodology you use, right? It’s just a question of whether that problem is visible to you or not.

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.

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

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.

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.

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.

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.

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.

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.)