How many times have you seen this in your projects: You need something specific done such as a new database, or a specific user interface designed, or you need a release engineer, or a user interface designer, or a part of the system tested and the normal person who does that work is not available? What happens on your project? Does it wait until The Expert is available?
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.