I was a pretty bad mentor for the early part of my career. Many things drove my team crazy (my arrogance, lack of empathy, and stubbornness, to name a few), but the biggest was refusing to help when they were stuck on a technical problem. My approach was to have them wrestle with the situation until they figured it out. So, even if it could be a three-minute fix with some help, I would sit back and watch it turn into a three-day saga. It sounds pretty stupid from a business and productivity perspective, but I sincerely believe that you can't learn from other people's mistakes. You gotta make your own. If you really fight with the problem and spend time on it - - You'll inevitably browse through ten wrong solutions first. Subconsciously, you'll pick up bits and pieces that would be valuable some other day. - You will remember that forever and also learn to apply it to other scenarios. If someone else gives you a fix, you will more than likely make the same mistake again—not today, not tomorrow, but oh, you will. I have changed a lot since then (well, that's what some would say), but my approach to learning hasn't. Unfortunately, it still bothers people (especially the younger crowd) as much as it did my first team. I hope some of my earlier team members found it valuable later in their lives. One can wish! ----------------- Hi, I am Maheep. Follow me for a candid, fun, and cynical perspective on tech and business. #thisandthat
This is a great perspective to learning Maheep Gupta. One analogy that aligns with this is “give them fish and they have one meal, teach them how to fish and they have meals for life” and giving them time and space to figure out a problem is the equivalent of teaching them how to fish. One middle ground I like to practice is that I give them time and space to really get into the problem and try to solve it every which way and then if they’re not able to solve it still, I explain them how I would approach the problem or where to find the solution and then give them more time to use that and solve the problem. Then if they’re still struggling, I walk them through the solution. This takes a lot of time on my end since it’s very involved and I need to be tuned into where they’re into solving the problem but that’s what it means to be a mentor right? Putting time and energy into their growth. I think mentors who solve their team member’s problems for them right away might feel like a blessing in the moment but are actually deterimental to overall growth!
Interesting perspective on mentorship. It's clear that finding the right balance between guidance and independence is important
Software Development Engineer @ Microsoft | Mentor | Master's degree, iOS development
4moThank you for sharing your journey and insights on mentorship. I find your reflections align closely with my own experiences and views on the topic. It's crucial to invest time in understanding the problem and attempting to solve it independently before seeking assistance. Providing context about the issue, the solutions you've attempted, and why they failed is always beneficial. Without this context, those trying to help may waste time on solutions you've already explored through a simple Google search, Stack Overflow, or developer documentation. Nonetheless, it's vital to weigh this approach against the urgency and timeline of the problem. In the fast-moving tech world, missed deadlines can lead to significant repercussions. Hence, it's important to time-box your problem-solving efforts before asking for help, ensuring that learning doesn't hinder productivity and deadlines are met. Mentorship, after all, is about guiding someone to discover their own solutions, empowering them with not just answers, but also the confidence and skills needed for future challenges.