My Findings From Being a Mentor
Nowadays I find the IT industry more and more focused on the so called “soft skills” rather than technical ones. We learn how to interact with each other and collaborate to be more productive as teams, not just work as lonely experts.
Last several months I participated in a cool initiative called “Kickstart” which took place inside Wix — we picked ten talented junior developers (out of more than a hundred) and over a period of ten weeks taught them all the basics they may need to start their career inside the company. We covered topics ranging from Front-end basics to TDD, NodeJS and Wix infrastructure. Over those ten weeks each student had a dedicated mentor (actually, two mentors — five weeks with first one and then five weeks with another one) to answer questions, support and lead a “kickstarter” on their path.
I was lucky enough to try on the roles of a lecturer and a mentor. And below I’d like to share my findings after this experience.
DON’T introduce your solution as The Only Correct One
Example: A mentee has read an article (or consulted with someone) and presents a wrong approach (from your point of view). You say it’s just wrong.
Why? This may form a strong belief in a student that there is always a perfect solution, a silver bullet to solving all problems. But if there are two opinions on which idea is the right one, both of them actually are correct in certain cases. This rule is especially important to understand for those cases when two mentors have different opinions on how to solve a problem and the student can get confused about which one is right.
Long-term they might not be able to find a good solution by just sticking to an existing “perfect” one without seeing that it’s just not a good fit in a certain case.
Alternative: Explain why the solution is good and when it’s not so good. If there are several possible solutions, try to find pros and cons in each one even if you personally don’t like one of them.
DON’T try to prevent a student from making any mistake
Example: You know that some kind of an application structure is better than others, you have been certain about it for years. Thus you want your mentee to do it the way you know is better instead of the way they prefer to do it.
Why? You surely have your expertise. And no one says you’re wrong. But one of the most effective ways to learn is by making mistakes.
One of the things I like most about the company I work for, is that Wix lets people make mistakes. Write some code, deploy, mess up, rollback as soon as possible and fix the mistake. You can’t be free and create awesome things without making mistakes. And it’s particularly important while learning — it’s very easy to learn anything by trying and failing, then by trying and succeeding (like children do).
What your mentee might actually need is guidance. Show them where to go, but let them go by themselves (even if sometimes they choose to go through a scary forest instead of a nice garden). And one more thing you can do is to help to prevent a mistake from becoming fatal (like making sure we have set up fast rollback, we monitor errors, etc).
Be ready to make mistakes by yourself. People make mistakes. And being a mentor is not only about technical knowledge, but also about learning how to collaborate. People who have just started their careers frequently think of themselves in extreme ways — today they think they know everything, tomorrow they think they can’t do anything. The truth is actually somewhere in between. Making mistakes can sometimes feel painful in both cases. Admitting mistakes and thinking of them in a positive way is a good way to balance — you should know you’re not perfect and you should understand that it’s fine. I think that it’s one of the more important goals for a mentor — to help a student balance this. Prove yourself and be ready to be wrong.
DON’T correct your mentee before understanding their solution
Example: A mentee shows you the result of his / her work and you say that it’s wrong at once and that they should redo it using some other approach.
Alternative: Before giving a piece of advice (or before starting an argument), try to understand how they got to a certain solution, especially if you don’t agree with it. Ask questions.
This can lead to one of the following outcomes:
- You can realize to be wrong if you dive just a little bit deeper
- A person will understand what is wrong with their decision by themselves
- In the end it might so happen that you have been correct all along. But having had the conversation you will be able to explain your reasoning better
I think asking questions when you disagree is generally a good way to communicate. And though it’s sometimes hard to do so instead of starting to argue (because, well, we’re human beings and we have our opinions), it solves many conflicts before they even start. Acting like this while mentoring is both a good way to prevent conflicts and give a good example of making good technical decisions.
Try to respect other person’s experience (even if it’s not so impressive) and their solution (even if it’s not perfect) and share yours as just an alternative.
DON’T expect certain pace or level… actually, don’t expect anything
Example. You’ve given your mentee some task and it looks like they’re doing it slower than you expect and/or asks you questions you consider to be “stupid” for their level.
What is it all about? All people are different — some students are calm and thoughtful while others are extraverted and fast. Try to adjust to their rhythm and don’t dictate yours. It may appear that the student is perceiving information slower of faster than you expected — in many cases it’s just because they’re different from you or from what you expect them to be. Remember that the goal is to help them learn and improve step by step. Let the mentee study at their own pace. Also, there are no “stupid” questions. It may be that you think a question is stupid just because you know the answer. But the other person just doesn’t have your experience.
Conclusion
I’ve mentioned a few common mistakes you can make, but you might get into your own pitfalls and might find you own insights. Those things above are not laws, they are guides instead. Try it for yourself and let me know if those were helpful or if you find them to be wrong.
And don’t expect yourself to be perfect. As I’ve mentioned before, the best way to learn is by making mistakes.
