Management Myth #2: Only ‘The Expert’ Can Perform This Work

Submitted by Johanna Rothman on Thu, 2012-02-23 11:08

Many managers feel as if they have limited options when a project is waiting for The Expert. They can make the project wait, they can ask The Expert to multitask, or they can plug another expert into that job. After all, The Expert isn’t needed full time on any one project, so it’s OK, isn’t it? Or, isn’t any database administrator, senior tester, or release engineer just like any other, even if this one doesn’t know your project backwards and forwards?

No, it’s not OK at all. It’s not OK to start a project starved of the people the project needs. It’s not OK to ask a person to multitask. And, people who don’t know your project aren’t experts on your project.

There’s another option. That option is to reduce the need for experts in several ways. You can pair the experts with others, you can banish experts altogether from your projects, you can manage the project portfolio so that you stagger projects that require expertise that truly is expertise, and you can hire more experts.

Never Let Experts Work Alone
Sometimes, the project expertise is expertise that can be duplicated among other people on the team. For example, maybe you only have one person who knows the build system, but everyone on a project needs to know how to use the build system. In that case, I like to ask the one person who knows the build system to pair with each person on the team, one at a time, until every team member knows the build system as well as The Expert.

By never letting The Expert work alone, you have duplicated the expertise among the team. Depending on the expertise, you might need an internal workshop first so that everyone has the same baseline understanding of the tool or technology. Sometimes, it makes sense for the release engineer to conduct an internal workshop for a few hours to explain the internal workings of the build system and then pair with everyone to make sure each person understands how to use the system. You can use the same model for many of the activities of database administrators.

This approach works well for technical skill expertise that is primarily tool based or based on a functional skill that is similar to another team member’s functional skills. It doesn’t work for everything. In cases where you have significant solution space domain expertise, where people need to know the guts of the code base, you want to consider other options, such as internal banishment.

Banish the Indispensable Expert
There are some people who appear to be indispensable. If they are working on another project and you want to touch “their code,” your project must wait for them.

Don’t fall for that nonsense. Banish them. Or, if they are working on your project, invite them to work on a different project. Whatever you do, move them off your project today. If The Expert is inside your organization but on another project, you still have access to The Expert. At some point, that expert will retire and start sailing the Caribbean sipping sweet rum drinks at 4 p.m. and you will not have access to The Expert. When do you want your team members to practice building their expertise? I want the team to practice while the expert still available.

The team has an unhealthy codependency on The Expert, and The Expert has a reciprocal dependency on the team. I’m no psychiatrist, nor do I play one on television, but in project terms, this is terrible. For the sake of The Expert’s self esteem, the entire team placates The Expert. This has the effect of preventing the rest of the team from learning the product.

If you work in a large organization, as a manager, you can arrange for The Expert to transition to another project. In a small organization, you can arrange for The Expert to work on a special project. Make sure that special project has plenty of deliverables so The Expert is busy and cannot opine on the old project.

The team will learn how to learn together. Once you remove The Expert, the team has a shot at becoming a real team, because now team members share a common goal.

Once you remove The Expert, team members will work together, and fast, to discover what they don’t know. They will share what they do know. But, you have to allow The Expert to be available a limited period of time every week. Maybe one hour, and then only if the team is stuck. Encourage the team to develop and use tests instead of questions to discover how the product works.

Stagger the Projects to Use The Expert
Maybe you don’t have an expert with a self-esteem problem. Maybe you really do have a limited number of experts with security expertise and you need them full time on a project. And, maybe you expected Project A to finish by now so Project B could start. But Project A is not yet done. Well, this is an easy problem to solve. If Project A is more valuable than Project B, don’t start Project B. If Project B is more valuable than Project A, stop Project A and start Project B. Yes, it really is that easy.

But, you say, we haven’t released Project A. Well, if you used an agile approach on Project A, maybe you have something sufficiently valuable to release. Maybe not. Too bad. Managing the project portfolio is a zero-sum game internally, so that you optimize for the entire organization. You do want the organization to succeed, right?

Project portfolio management is all about having the difficult discussions at the organizational level so you don’t do two projects at the same time, slowing down both of them.

Which project is more valuable, Project A or Project B? Which project moves the organization forward? How little can you do and still have a valuable release? Those are the kinds of questions you need to ask.

If you haven’t been using an agile approach on Project A, it’s not too late to start. Finish the features that are close, then rank the rest of the features. Let’s hope you started working on features in something like rank order.

Hire More Experts
If you really want both Projects A and B to proceed simultaneously, you have to hire more people. Even so, it will take a while to hire more people and have them up to speed fast enough to make a difference. But, hiring more people will help.

Understand the Root Cause
One of the reasons we have so much multitasking in our organizations is that we have so many experts with narrow expertise. The more narrow the expertise, the less any one project needs that person, but when you need that person, you really need that person.

We have many myths about needing Experts and Only Experts to perform specific work. There is some work that only experts can do. The real question is this: how much? I don't expect developers to become testers or vice versa. Nor do I expect UI designers to become security experts. But as a manager, I expect everyone on a project to learn enough about the project to be conversant about the entire project. And, most importantly, I expect experts to work with others to share their knowledge.

The more people you have who can take a more generalist approach to product development, the more flexibility you have for your projects. So when I say, “Work flows through a team,” you agree with me and say, “Of course. How else would it work?”

You don’t have to eliminate The Experts; you want to reduce the need for them and raise everyone’s technical competence and capability in your organization.

Read more of Johanna's management myth columns here: