“Don’t tell me how to do it, I know what to do!”​ If you have said this or this has been said to you, read this article.

Here is a real situation; I have come across this in about 40% of the one to one sessions I have had with people.

(I refer to the engineer as “he” to reflect the real situation.)

You are a team lead and you have an engineer on your team who thinks his way is right; however, doing it the way he wants is not producing the desired results. He keeps throwing the work back to the implementation team, stating that the problem must stem from them, that the issue is with the code they delivered.

You try to perform some deeper analysis, and ask him: “Have you tried X methodologies or Y commands?”

His answers are:

· “I have already done X, I have already done Y,” or

· “I was just thinking the same, I will try it out.”

· Sometimes he becomes frustrated and says: “Don’t tell me how to do it, I know what to do!”

Initially you trusted what this engineer was saying, but when you tried those methodologies and commands you discovered there was a significant difference between his findings and yours. When you dig deeper, you discover he did not carry out the detailed analysis you needed, he just sent it back to the other team, saying it’s their problem.

You now feel you have to do double the work and you end up working overtime to do his checks and yours.

The most common question I get from engineers (who might also be team leads) about this situation is this:

“What is the right way and the right stage to deal with this?”

In order to deal with this situation in “the right way,” you have to understand what just happened. (If you want to know what to do without understanding what happened, scroll down to the bottom of the article.)

I have spoken to several engineers who are that person the team lead is complaining about in this scenario. The information below is based on those real conversations.

Here is what is happening

The engineer does not know exactly what the team lead needs to achieve. The engineer in this situation also often doesn’t listen to understand, he simply listens to respond. This is because he thinks that he always has to have an answer for everything and does not disclose that he doesn’t understand exactly what the team leader is after.

Moreover, in general, engineers can feel patronised or irritated to be told HOW to do their job or to be asked things such as “Have you tried X methodologies or Y commands?”Often, the most exciting part of an engineer’s work is to figure something out or to find out how to make something work; by telling them how to do it, you are taking 90% of the fun out of it. This may also be why they are resisting the situation.

If he doesn’t know, why doesn’t he ask for help?

Many engineers don’t feel able to ask for help. I think this is partly because they like to work things out for themselves; I also wonder whether the years of education they have experienced have taught them that they have to know the “right” answer. I have said this before, and I believe is an important point:

One reason why engineers don’t ask for help, and often don’t admit they don’t know what you need, could be perhaps in academia they are encouraged to find the right answer and argue the facts.

In prestigious universities such as Cambridge and Oxford, engineers have to hold strong opinions and argue for them, even during the admissions interview. If they are lucky enough to get in, their lectures are full of debate: to get ahead, they must hold strong opinions and defend them.

When they graduate, these engineers go into the corporate world, where they are expected to work collaboratively, ask for help and reach consensus.

But this consensus culture, in the main, goes against the behaviour that helped them do well at university.

My guess is that some people don’t recognise the culture shift and might still think that not asking for help, and holding strong opinions and fighting for them to the end, is the only way to be at work. Given the debating culture they went through in the earlier years, I can completely see why they would think that.

Look at the question that team leads (who are engineers) have asked: “What is the right way and the right stage to deal with it?” This question assumes everything has a black and white correct (right) answer.

I think in the same way; that’s why this kind of thinking resonates with me.

So, what Is the right answer, in this situation?

There are a few things that the engineer needs to know: what sort of result is the team lead after; what exactly does the team lead need to know; what does “good” look like; what sort of outcome should he aim for?

He needs to understand what you need to know.

Instead of “Have you tried X methodologies or Y commands?” try saying (variations of) things like:

• · “We need to achieve X. What else could try to achieve this result?”
• · “Given that X needs to be able to do Z, but at the moment it only goes up to Y, and you have already tried ABC, what else do you think you could do to get it to do Z?”
• · “What result/number/parameters did X command give you? Why do you think it gave you this result?”
• · “What data/evidence/information did you get that demonstrates that the problem in the code stems from the implementation team rather than from our team?”
• · “Where does X result come from? What do you think the reason is that we are getting this result?”
• · “What have we tried so far that made you realise this is the best we can get with this? What else can we do to achieve X?”
• · “The result would have to be somewhere around X because of ABC. What else could you try to see if we can achieve X? Why would this not work?”

Engineers dislike being told what to do, especially which methodology or commands to try to work out a problem. Often, they will not ask for help, and sometimes they may not even realise they don’t know what you need. In order to help them achieve the results you need to move forward, you have to guide them and help them to understand the outcome you are after. If you TELL them HOW to get there, they are unlikely to listen to you, and they can end up feeling antagonised. Instead, talk about the result you need and ASK for their help to work out HOW to get there.

What other ways would you unlock this situation?