How to Manage Subject Matter Experts When You Aren’t One

It’s hard enough to lead a team when you know more about the topic than your junior reports. (“Let me show you how it’s done!”) But quite often, project managers hire someone (internally or externally) because they don’t know anything about the topic. You bring in a Web designer, an architect, or social media specialist because you lack that expertise. Still, you need to ensure that the contributors get the work done with good quality, that they learn to do their jobs even better, and to reassure yourself that you aren’t getting screwed because your “expert” actually doesn’t know doodly-squat.

This isn’t something that applies to us only in regard to project management, of course. We all encounter that gut-gnawing nervousness when we look for professionals to depend on, whether it’s an accountant or a car mechanic. We have to balance the awareness that we are not experts with the fact that occasionally we do get the wool pulled over our eyes.

Hiring such people is one thing – that’s what references and interpersonal skills are for – but managing them is another.

So let me share some advice on managing people who are experts in something you’re an idiot in.

Trust the people you hire.

Successfully managing any team means that you respect the individuals who come to the table. If you did a decent job of selecting the right people (and you probably did), let them do their jobs. If you have thoroughbreds, let them run. Management of top-notch people is often quite simple: Tell them what you need and if they don’t deliver it, get rid of them.

This includes a pep talk, too: Give yourself permission to not pretend to have the expertise you lack. Recognize that you don’t know everything, you never will, and – as project manager – you shouldn’t. Your role here is to ensure that the work gets done, not to do it all yourself.

“Face up to the expertise disparity from the beginning,” one techie told me. “The good managers I had would readily acknowledge my expertise, and articulated that as a separate area than their expertise, so there was little conflict.” Bad managers try to minimize others’ expertise or act as if they had more. If the roles and areas are separate, there is no conflict and little ego.

That doesn’t mean you should assume the expert has everything under control. Trust, but verify. Monitor progress closely. Stay in the feedback loop. If the project is going off-track, make sure you know as early as possible. That is, don’t wait until the website is supposed to be finished to check on your experts; have lots of checkpoints so you can recognize if things get off the rails.

Establish and watch useful business-based metrics.

To watch an expert’s progress, you need some way to measure what has been accomplished. The best way to identify if the job is done varies quite a bit based on the project scope, its timetable, whether the expert is staff or an outsider, how much is repeatable (something that’s been done before versus designing something new), and presumably several other variables.

But the bottom line is that you need to be results-based and measure. Measure by units that anyone can understand, and make the “completion units” small until trust is earned. “A miracle happens here” is fine if the output is what matters. But look for something tangible, measurable, that you understand, to be completed at least once a week.

However, if you hire someone to do the job don’t review every nail he drives. I’ve seen this too often: In an effort for the boss or client to monitor progress, the experts are asked to spend a ridiculous amount of time in reporting, meetings, and so on. The measurement processes should never hamper production.

You might be tempted to eschew metrics (which take time to set up and review) in favor of your gut feel and people-reading. After all, you think, your expert seems really nervous and is always apologizing for her uncertainty; that probably means she doesn’t know her stuff. Or he puffs up his chest and tells you how great he is; surely he would not get away with that if he didn’t know what he is talking about. However in my experience it is a major mistake to assume that confidence equals competence – in either direction.

In most cases you should define the metrics based on business requirements and the key milestones, including a clear specification of expectations. For example, create a document that clearly states the product’s expected features.

When your expert misses a target, work to reset the milestones; this will happen if a project is sizable and especially if the expert has to spend a lot of time working with staff (you and everyone else on the team) who often need explanations. Don’t criticize the expert for missing a milestone, but do watch for repeating patterns. A pattern of constantly missed deadlines may indicate that this expert isn’t expert enough for this project – or at least the project was ill defined (which lands back in your lap).

When it’s important, get a second opinion.

Don’t be afraid to bring in outside expertise, perhaps on a short-term basis, when you-as-manager are unsure of the situation. If you can’t develop internal sanity checks, find them outside your group or company. Sometimes a trusted customer works.

For example, when the expert gives you the aforementioned specification, pay a few outside experts to review the document and give feedback. (Depending on its complexity, that payment may be cash money or an especially nice assortment of dark chocolate truffles.) Are there any gray areas that really should have more detail? How much resources and time would they expect to be required to produce that product? Share the feedback with your subject matter expert; this shouldn’t be secret. Your expert might not agree with the other people, but it should help all of you ensure that the expectations are clearly set.

Just be careful about whom you ask to provide the second opinion. The fastest way to make any professional roll her eyes is to ask about the time the boss asked his “expert” brother-in-law to review something the professional did. Your brother-in-law might indeed be an expert, but then again he might not. And worse: You put your team member in an untenable position. I clearly remember one source bemoaning this situation in an article I wrote several years ago, Getting Clueful: Five Things You Should Know About Fighting Spam. He was frustrated by managers who don’t understand how the technology works and assume that his tech expert – the mail administrator who worked hard to keep up with his area – was far less knowledgeable than the boss.

“They spent some money for some software; why is spam still getting in? Even worse: Why did the system block mail from my nephew? He is running a mail server on his cable modem; he clearly knows how to set up a mail system, why can’t you? Explaining why his nephew’s mail server is in dozens of public blocking lists for being a spam cannon is a lot harder than you might think. How do you do it without implying his nephew is an idiot?”

Which leads us back to the subject of respect and trust.

Learn from your experts.

You don’t need to know everything that your team member does. You only need to know enough to ensure that the expert has the resources necessary to do the job. But to the degree you understand the subject matter – even from a 30,000-foot level – you can provide better managerial feedback and possibly offer useful advice.

Ask a lot of questions, listen to the answers, and regularly solicit feedback. If you make a decision different from what the expert recommended, take the time to explain why.

But, but… You don’t understand their technology! You’re lost with that end of the business! Surely your eyes will glaze over in nanoseconds?

Nope.

Expect your expert to speak to you in English. Be straightforward, and bring the discussion back to the business need. For example, you might say, “Please don’t use technobabble. We have an obligation to our business to communicate in their language. Explain this to me in business language because that’s how we talk with our users.” Let the expert know that when you are armed with the right information, you can talk (accurately!) with senior management in the meetings that the technical team wants to avoid.

Do this in a friendly, Socratic manner, and you often create a willing participant in the conversation. After all, experts enjoy demonstrating their expertise and we all love to tell our own stories.

Ensure that your experts have an opportunity to learn.

By the definition here, the expert is the only person in your department to understand the technology or business practice. As project manager that makes you think first of the team’s needs… but as manager you should also think of the employee’s needs.

It’s important for you as manager to create an environment that helps every team member be successful. Make sure everyone has a decent place to work, the right quality assurance testing, the proper supply chain, everything that helps every team member be successful.

That’s true everywhere, of course, but it matters most here. On a team where your expert is the only person who knows about the subject, she is left to her own devices when it comes to improving her skill. That was true for me, once, when I was the only programmer on a team with 70 mechanical engineers; I got feedback but no mentoring. Since you can’t offer specific advice (“Here’s how to improve that design…”), make sure the solo expert gets external training from trustworthy sources. Send your expert to conferences, for example, where she can interact with others in her profession.

Every project manager makes decisions on matters that are beyond their technical expertise, and there is nothing wrong with that situation. That’s part of leadership: Create a team of experts working towards a common cause. Demonstrate to those with deeper expertise that nonetheless you are in alignment with them on goals. That makes you an ally and an asset, not a nincompoop who doesn’t understand their needs. Instead, they know why you value them and the knowledge they bring to the project.

Trust takes time, and it takes patience, and along the way, if you are paying attention, your own knowledge in the area goes up as well.

via Business 2 Community http://www.business2community.com/strategy/manage-subject-matter-experts-arent-one-0596219?utm_source=rss&utm_medium=rss&utm_campaign=manage-subject-matter-experts-arent-one