As a mentor, how to interact with the team to adopt my thought processes and suggestions?

Question

I am the Tech Lead of a team. I am usually there for the team's technical challenges, code reviews, quality processes and the like. No one in the team is a direct reportee, all of us report to a common Manager. So you can see that I do not have any authoritative position as a lead. Also on their performance my reviews are just a "feedback for further consideration" to my manager. I am also an individual contributor.

My situation is such that I only need to solve "technical" or "architectural" challenges which the team comes across. However, the qualitative or suggestive approaches I make during such problem solving are usually not paid attention to by the team. They do not have an open, accepting nature to my suggestions. As long as their code is "fixed" and all quantitative metrics are met, they are not bothered.

My Manager expects me to "mentor" them so that they can adapt these best practices I preach and follow. Essentially he wants me to mentor them so that they learn the "tricks of the trade" - put simply, get skilled the way I am.

However, apart from the problem at hand & its exact solution, the team is not ready to collaborate, follow or adapt. There are set standards & processes they already follow but it seems like they do not want to "grow" according to my suggestions. It's not that they do not listen, I do not see them adopt the approaches I suggest the next time.

How do I change my approach so that the team starts taking interest? Or should I convey this situation to my manager since he is expecting the team to get more "skilled". I do not want to sound "complaining" to him against the team that no one is interested.

Answer 1

Mentoring someone by saying "Do it this way" is not enough, you have to explain "Do it this way because of that advantage and because the other way has this disadvantage".

What makes employees good employees is basicly work experience. The best practices you're trying to teach them stem from decades of work experience from several very talented people. They didn't just come out of thin air, but were developed to solve certain problems.

If you make your team experience the same problems (of course not in reality but by explaining them to them), they might be more inclined to actually adopt and implement those best practices.

Answer 2

It sounds like you are positioned essentially outside the team. You are available to consult on technical challenges and to review code, but you aren't working side by side with the team on their project.

This puts you in a difficult position, because it's hard to earn respect that way. You may well have much experience and knowledge to impart, but without the respect of the team, they won't be receptive.

You should make an effort to be working with the team day to day, even on more mundane tasks, not just architectural design. That will allow you to pass on more information and knowledge in a more natural manner, as part of the day to day routine. It will bring up more opportunities for you to point out solutions to problems as those problems come up. As the team sees this they will be more receptive to your approaches.