5

What is an effective strategy for working with individuals who have very little experience in a specific domain (they may be experts in their own domain), but still reject input from a subject matter expert (SMEs)? These individuals don't know enough about the specific domain to recognise that they're adopting a flawed approach, but still reject the advice from an individual recognised within the company as an SME believing that they know better.

It seems to be a textbook case of colleagues demonstrating the Dunning-Kruger effect.

I'm asking the question from the perspective that I'm the SME, and a poor outcome by the other employee who ignores my recommendations will reflect poorly on me when management finds out what has happened.

Please note that I'm not referring to instances where there are competing objectives (timing vs accuracy vs company politics), but instances where taking the SME's advice is unambiguously advantageous for the company.

Edit: I've removed the examples as some responses were focusing on the minute details about what was/wasn't said in each example rather than on the higher level question. Without making the question several pages long it is not possible to provide every relevant detail in each example.

A more generic example of the behaviour (which highlights the benefits of Kevin's solution):

  • Employee: I am going to do action X. I'm required to discuss this with you because you're the SME for this work stream.
  • SME: I can see some ways to improve X, maybe if we implemented actions Y or X+Y we would get a better outcome.
  • Employee: No, action Y is wrong/not necessary, I'm only going to do X.
  • SME: Some reasons you may like to consider action Y are (...)
  • Employee: Action Y is still not necessary. Action X solves the problem.
  • SME: I can help you implement Y alongside X if that would help.
  • Employee: Your advice about action Y is wrong. I don't need help implementing my solution action X.

The three solutions I've seen employed in the past are:

  • SME escalates his/her solution to the employee's manager, sidestepping the employee and making clear that the SMEs advice was not followed. This can come across as passive aggressive and begs the question why the issue couldn't be solved before it was escalated.
  • SME lets employee make a mistake then points out the mistake to management after. This appears counterproductive and passive aggressive.
  • SME goes 'full Tucker' on a employee (with an audience present) to aggressively demonstrate how little the employee knows about the topic and embarrass the employee. While I've seen this approach work in the past, it's obviously undesirable for many, many, many reasons.

To summarise:
What is the best way to resolve a disagreement when you are hired as a subject matter expert and a colleague is ignoring your domain-specific advice?

| improve this question | |
  • How did you learn about Incident 1? You say that the DBA refactored the code and the result was a 20x improvement. Can either you or the DBA substantiate that? This sounds like an issue the Engineer X's team leader could take care of in two seconds if the 20X improvement can be substantiated. – Vietnhi Phuvan Nov 20 '16 at 15:16
  • How did you learn about Incident 2? This sounds like an issue that can easily be resolved with a senior engineer mandating that the junior engineer use the existing software package. – Vietnhi Phuvan Nov 20 '16 at 15:18
  • I take it that Incident 3 directly involves you. All you need to do is communicate to management that the work can be done irrespective of engineer Z's objection. – Vietnhi Phuvan Nov 20 '16 at 15:20
  • It looks like you could use a manager that you can escalate matters to when the junior staff is objecting and dragging their feet. In each example, it looks like it's much easier on everyone and the firm would be better off if the junior engineers tried it your way first. Has your employer been explicit regarding your authority over these wayward folks? Has the firm made someone with managerial authority available to you to support your efforts? – Vietnhi Phuvan Nov 20 '16 at 15:24
  • Who is Engineer X's boss (who can fire him)? – Brandin Nov 20 '16 at 15:27
19

When someone rejects an advice, it is often useful to dig into why they chose that. When the person rejects, it signals they don't agree with the recommendation. Enforcing "I'm an expert" or "this is a company policy" does little effect without digging out the root cause.

A couple of possible reasons:

  1. The person does not understand the technical reasons. Some technical reasons may be counterintuitive to those who have little experience. (e.g. If the plane is stalling (falling), the pilot should push the nose down, pointing to the ground, not up. Pilot trainings go to great length to make sure pilots understand the aerodynamics behind).
  2. The suggestion is causing extra workload to the person. E.g. a secure database design should store passwords in hashed values. If the developer is unfamiliar with hash functions, he may deny to change his clear-text code approach. Or, perhaps the developer has already finished all login logic. So what he is requested to do, (from his point of view), is essentially throw away all his previous work and start again! Needless to say, that would meet some opposition.
  3. A suggestion which looks trivial is actually very complicated in another domain. E.g. A boss once requested his developer team to do this: implement a textbox on day one, implement a textbox with colored text on day two, then implement a textbox with bold, italic, hyperlinks, images etc. on day three.
  4. It is a personality problem. In that case there is nothing you can do. Ideally, interviews should have screened candidates like this, but that's not always the case.

The gist of it is: I'd spend (some) effort trying to understand why from that person's perspective. It is a bit time consuming; but if you can do that, it'd become a great management skill.

| improve this answer | |
  • Even in case of number 4, there is still the usual advice of leaving written proof. If the expert doesn't want to involve the employee's manager, he can still send an e-mail laying out his concerns to the employee himself. Depending on the severity of the expected impact, the employee's manager may need to be contacted though. – user7019377 Nov 22 '16 at 19:25
3

If you look closely at the situations you described they could have been handled much better better by the SME which could have lead to a better resolution. IT appears that the issue isn't as much that someone wants to ignore the advice but the method of giving that advice causes push back.

Engineer X develops software to monitor equipment performance. The software is very slow. Engineer X complains to the Database Administrator (DBA) that he needs to upgrade the database server to fix his problem. DBA identifies that engineer X (who has no database experience) is running inefficient code and rewrites the code for Engineer X, delivering a 20x performance gain. Despite having been shown that the new code is much faster, Engineer X rejects the change instead reporting to management that his software doesn't work because the DBA won't upgrade the server.

This seems like a common occurrence where you have an engineer writing code to access a database and they don't have the necessary training to maximize efficiency. However in this case like this where the expert just rewrites the code and says it will just cause issues like this. While it may surprise you there are many people who don't react well to being told their work is garbage and being handed a fix. Not to mention that if an engineer is writing code that is this bad for one application they are probably doing it for others.

To me it seems like a better solution would have been for the DBA to reach out to the engineer to help them improve their code which would help improve all database related code they write.

Junior Engineer Y proposes to take two weeks to write an algorithm from scratch. A Senior Engineer suggests the Junior Engineer use an existing software package that already implements the required calculation. Junior Engineer Y argues that the existing software package does something slightly different and therefore does not have the required functionality, despite all evidence to the contrary.

Remember that one of the jobs of a junior engineer is to learn and that one of the jobs of a senior engineer is to help them learn. When you have a situation like this it would be better for the senior engineer to work with the junior engineer to understand why they think that the existing software won't work and help them understanding why it will work. If they can understand why the existing software works they would be more willing to change.

Engineer Z obtains data from a SME. Engineer Z argues that the data is flawed because two columns in the data set don't reconcile. SME points out that it there would be no reason why the two columns should reconcile. Engineer Z reports to management that he can't proceed due to flawed data.

In this case if an engineer says the data is flawed and they can't proceed but the SME says that data is fine there is a misunderstanding of what the data means. It shouldn't be that hard to see that not everyone will have a full understanding of the data in a complex system. Unless the SME's are willing to spend the time to help explain there will be a push back.

Employee: I am going to do action X. I'm required to discuss this with you because you're the SME for this work stream.
SME: I can see some ways to improve X, maybe if we implemented actions Y or X+Y we would get a better outcome.
Employee: No, action Y is wrong/not necessary, I'm only going to do X.
SME: Some reasons you may like to consider action Y are (...)
Employee: Action Y is still not necessary. Action X solves the problem.
SME: I can help you implement Y alongside X if that would help.
Employee: Your advice about action Y is wrong. I don't need help implementing my solution action X.

In this example there is a failure to explain anything about why action Y or Y+X would be better. The person doing the work does not see the need for action Y and appears to think think that it is wrong. An explanation of why it is needed would go a long ways toward getting it implemented.

| improve this answer | |
  • Did you not even read the quote you posted? SME: *Some reasons* you may like to consider action Y *are (...)* – Amy Blankenship Nov 22 '16 at 18:16
  • @AmyBlankenship Saying some reasons you might like to consider is not the same thing as explaining it. For example if the reason is because Y will be less work that doesn't explain why the less work is better. Someone can give you hundreds of reasons why something is better but if they can't explain/justify it to you then it doesn't matter – Joe W Nov 22 '16 at 19:31
  • If anyone is employed and doesn't understand why less work is better, they need to be fired. Reasons are actually explanations of why to do something. – Amy Blankenship Nov 22 '16 at 19:49
  • @AmyBlankenship When less work leaves an existing problem/flaw in place because you don't want to take the time to properly fix it that is a problem. How many times has a security issue caused trouble because it was more work to fix and remove issues then just keep things the same. Also reasons are not explanations, just because something makes sense to you doesn't mean it makes sense to everyone. – Joe W Nov 22 '16 at 20:02
  • I think you're getting really splitting semantical hairs, and a reasonable person can read what the OP said and see he covered the explanation part – Amy Blankenship Nov 22 '16 at 20:03
2

This is being done incorrectly from the start. What is needed is a clear contact protocol. If a developer needs the database server upgraded, this request should go to his manager, who after deciding it's reasonable sends it to the head of the server people to analyse the problem or delegate analysis and action.

The developer shouldn't be communicating directly, then the analysis if it's decided the dev is in error, passes back through the chain etc,. Until there is a resolution and decision made by someone along the way who actually has the power to enforce it.

I'm an engineer, I don't even reply to any requests that don't come through the correct channels except sometimes with 'Hello, this needs to be approved and come through XXX first.'

| improve this answer | |
  • Ugh. Some workplaces are like this, I suppose, but others thankfully are not. – Ernest Friedman-Hill Nov 22 '16 at 13:10
1

As a complement to kevin's answer :

What is the best way to resolve a disagreement when you are hired as a subject matter expert and a colleague is ignoring your domain-specific advice?

One word : Organisation.

First : yes the developper is at fault too since he ignored the expert.

However the real problem lies here :

Employee: No, action Y is wrong/not necessary, I'm only going to do X.

The fact that the developer decide himself what he will implements is the problem. He shouldn't have received the request to do X, he should have received the request already checked by the expert to do X and Y from his upper line (or the project's one).

It doesn't mean you need a highly complex chain like you may have in some organisation (see @Kilisi answer) but you need at least one entry point in the project which is the responsability to make a produce a clear specification (even technical) reviewed by the experts and then hand it to the developer and follow that it's been done properly.

TL;DR This project lack a project's manager or he isn't doing his work.

| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .