Who mentors the mentors
being cautious who we are learning from
At some point, everyone is thought to question everything. As children we were full of wondrous questions about every minuscule detail that surrounded us. With age we don’t exercise our right to question as much as we should.
We are introduced to many teachers and mentor figures right from the start of our education. First with our parents and/or guardians, followed by school teachers and tutors and finally life itself. They’ve partaken in the process of building our knowledge and our personalities. One thing that isn’t mentioned as often as it should be is how often do we actually question the teachings of our mentors.
Not wanting to go into existential territory, in this article we will stick to mentor figures in the software development industry.
Mentorship
First of all let’s define what a mentor figure is in the programming world. As mentioned by Jess White in an excellent Unhandled Exception podcast episode, a reasonable presumption can be that a mentor figure is someone who’s profound in guiding ones learning and development. Someone who’s there providing help when professional roadblocks arise. In the same podcast, Jess White makes clear distinctions between the possible mentorship roles: Mentor, Coach and Sponsor. While I agree with the clear distinctions between those three types, I would also add one more type that barely touches on the subjects the other three are covering, but it should be at least mentioned and that’s: Instructors.
In this article we will mostly focus on the first one, mentors.
Mentor background
How often do we question our mentors’ knowledge and background about a subject?
All too many times, we are plainly ‘assigned’ a mentor figure by some higher-ups. Right there, there’s the first wrongful step of presumption that the assigned person has the necessary knowledge and know-how to pass some of that knowledge onto us. The truth is, as so many times, much murkier than that.
Many of the mentor figures we take for granted are there by default. Maybe it’s their years in the industry, title or simply lack of staff in a company. A good mentor figure will introduce themselves and present their role and background, their expertise and their shortcomings.
A mentor should not be automatically associated with having all the knowledge in the universe about a topic. Their expertise doesn’t even have to be in the same industry as the mentee. Generalization is a tricky subject all by itself. A mentor that can guide you through a difficult learning or problem-solving process with examples and possible approaches is crucial for any industry. Sadly, the most prevailing thought is that mentors should know everything or at least a good portion of the possible problem scenarios and topics for a given field. While that might be the case in a very limiting or specialized subdomain, that same thought is simply unrealistic to be applied to a vast industry such as IT and software development in general.
Instructors vs mentors
It is important to distinguish between these two figures. Unlike mentors, instructors have a more executive approach in dealing with their pupils or trainees. There’s no individualized element with dealing with instructors. They do not adapt to their trainees, the trainee adapts to the instructor. They provide clear and unambiguous set of commands that are expected to be executed precisely as instructed. No questions asked. There’s little to no leeway in interpreting a set of instructions. Instructions often come with bare minimum of explaining. Also worth mentioning is that instructors are also focused on constant improvement for existing instructions. In software development, as an example, this can be manifested as a more strict set of rules that a company abides by. Company guidelines if you will. This is perfectly fine in certain high-risk areas, but for most use-cases, this can lead to a more counterproductive outcome. Certain procedures are expected everywhere, but when it comes to problem solving not everyone is expected to perform the same way. That’s why it is important to recognize instructors early on and assert if one is truly needed on a case-by-case basis.
Mentoring or providing onboarding guidance
Amongst other topics that should be recognized early on in a mentor-mentee relationship is if the mentor is providing actual mentoring or providing onboarding guidelines about a project and approach to it. This can be easily identified as a rehearsed speech that lacks the needed depth for individualization and a very narrow window of time for which the mentor is available to the mentee. They are there at the beginning stages of the onboarding process. Providing guidance and making sure that the mentee has all the necessary tools and information to start their work as soon as possible. They do not go into depth for any subject and rarely ask follow up questions. These mentors might seem similar to instructors, but that’s not the case. They are indeed there for the mentee, but as mentioned earlier, they only have a set amount of time dedicated for the onboarding process before moving on with their daily activities and becoming unavailable to the new personnel.
Mentorship traits
It’s a thankless job to put down all of the traits a good mentor should encompass. We all look for something different in a mentor. Some see them as problem search engines and others see them as someone who’s willing to do their job for them. Whatever the case might be, we’ll try and mention a few traits that would be greatly appreciated in any type of mentorship.
Clear statements
You might think that I’ve provided mentorship to my team and team members at a level that is reflective of the topics that we covered in this article thus far, but that’s simply not the case. Like so many mentors, I simply grew into the role. It was “expected of me”.
Over time, I’ve recognized certain patterns and potential faults in my mentorship approaches.
Years ago, at first, there was the information overload problem, where I would provide a lot and even more information about a given subject that, when looking through the eyes of a beginner is total information overload and the mere thought of expecting someone to sponge in all that information at once is plainly ridiculous. Mind you, no one actually approached me with a feedback and critique about this particular issue, because of unknown reasons and also because of the illusion of providing so much knowledge and information that couldn’t possibly be harmful, now. Could it be? Let’s see… Given a subject matter of mathematics, would it be good if the teacher comes in on the first day of class and for 45 min. just pours out all the ‘cool’ and “exciting” subjects from the world of statistics and probability? Yes? How much do you think you’ll recollect from that information an hour after the class? How about 5 hours? There’s a reason why that particular subject is taught for multiple semesters in high schools and universities. And that’s just a tiny part of mathematics theory. Imagine someone’s giving you the sales-pitch for mathematics in 45 min. The best outcome is that they would awaken your interest, actual knowledge takes a back seat here. Same goes for IT. Let’s take a step back and doze our information as we move forward. If you simply can’t help yourself, limit the information overload to a teaser at the end of a mentoring session. Leave them wanting more. A TV series cliffhanger approach of sorts.
Other than the problem of information overload, I had (and still kinda do) a problem of providing clear statements about a subject. What do I mean by that? Many of the problems presented in the software development industry can be solved with different approaches. My own fault was to showcase multiple solutions where applicable before solidifying one of the possible solutions or before forming a digestible solution beforehand. The result of this approach is muddying the waters and leaving the mentees more confusing. The same can be said with presenting a problem. If it is not clear what a problem actually is and what the potential outcomes of said problem are, one cannot understand why they would focus their time on a solution. During my school years, I had a tough time with classes where the teacher would start off a topic with writing a solution on the board before even presenting the problem. For 20 min. we would stare or copy the content written on the board only to find out where that particular solution can be applied to. This is of course a personal stance on the subject and others might be content with that kind of teaching approach.
Offering clear answers, even stating that you might not know something, is more effective than engaging in continuous rambling about different scenarios and solutions to a problem that only needs one in order to move forward. When solidifying one answer or statement, we can advance into other possibilities depending on the use-case.
I always liked the famous quote by Albert Einstein: “If you can’t explain it to a six year old, you don’t understand it yourself”. There were so many times in my past where a teacher would over-complicate their answer when explaining a topic. Focusing on software development, one does not need to draw a complex scheme with lots and lots of surpurpleous decorative entities in explaining how a design pattern works or how to print some basic output to the console. I remember when a teacher used to explain the concept of pointers in C++ to us in an example that spanned well over five hundred lines of code and multiple presentation slides or another teacher explaining how some simplistic shaders worked in OpenGL in the same manner. The important thing here is to note that we were just starting to learn about the core concepts of the programming language and graphical framework respectively.
One subject focus vs information overload
I’ve mentioned in the previous paragraph that this was one of my personal problems that I aim to improve upon going forward with my career. It’s very tempting to move on from a subject if it’s easy enough to explain and understand. Even though a subject might not be complex enough to demand a full mentoring session, we should still maintain the focus on that subject for the time being. The time can be filled with reinforcement learning and multiple examples if need be.
We should distinguish between listening and understanding and actually implementing something in a practical setting. While someone might on the surface level understand a subject, it’s perfectly fine to challenge that thought with a demonstration or even a knowledge test. So many times we think that we understand a topic, but when the conditions are met to showcase it, we tend to fall short. Why is that? The main reason behind this is that we use different parts of our brains for storing new information (listening, reading, etc.) and for recollection of the same. There’s a reason the saying of “repetition is the mother of learning” exists. So many classes encourage us to experiment and to do something all by ourselves. While we all have our preferred ways of learning, this can be a valuable asset and habit to be formed when diving into new subjects or projects. That’s why we have frequent tests after a section of the curriculum is covered in classes.
Let the current subject sink-in before moving to a new one.
Waiting for questions. Encouraging questions. Asking random questions to the listener
A trifecta of questionnaires. It is principal to give enough breathing room to the mentee to process the information provided and form any potential questions about a topic. If the mentee proceeds through a mentoring session or multiple ones without asking a single question related to the topic, it can form a layer of insecurity with the mentor about their abilities to convey difficult topics or to properly engage with their audience. Finding the right pause moments in a teaching session and engaging with the listeners and potentially challenging them with your own questions might break the ice and encourage followup questions. It’s necessary to remember that the mentor-mentee relationship is a two-way street and a mentor is not there just to pour information into some collective knowledge glasses but to have proper conversations.
Unlike many presentations or talks where the questions are usually reserved for the end of a presentation, a single mentorship session should be split into multiple chunks of conversations without breaking the flow of the session, that is, no jumping around or steering away from the planned topics. There are times where a session can switch to a completely unplanned topic that has a higher priority level than the planned one, such as finding out that the mentee might already possess a solid understanding of a subject and is eager to discuss something that is more in-line with their problem domain.
Open and honest
A trait that is welcomed in both personal and professional lives. Being open about the level of knowledge about a subject and honest about potential shortcomings, brings in the “human” factor into a relationship. It breaks the illusion that the mentors are all knowledgeable and untouchable with their statuses being on another plainfield. Mentors are challenged all the time and when the situation arises where one might not have the answers ready on a dinner plate, but feels like one should have it ready, those are situations where their openness and honesty either comes out or something else that might be more damaging fills-in the place. It’s almost dangerous to form an aura of all knowledgeable invincibility around oneself.
If a mentor is in the assigned-by-default position like we mentioned earlier, they should be open about it. The lack of mentorship experience and difficulty in finding the right path for themselves and their mentees. A subject or question comes along that you have little understanding of, just be open about it. Turn that shortcoming into a learning session with the mentee where you both can learn together. Maybe even showing them a personal approach with dealing with new problem domains.
There are absolutely individuals out there that possess encyclopedic knowledge about a domain and they deserve all the praise and acknowledgements, of course, and it’s worth remembering that their availability and demand is proportional to that knowledge too.
Standardized level of experience
When assigning a mentorship role, ideal candidates should have a minimal level of experience on the subjects that they would potentially be covering. Going with personnel that on paper might seem like ideal candidates that have accumulated a certain amount of working experience in the topic should be just one of the steps in the selection process for the role and not form a complete picture. Just because someone has held a certain position for a long period of time doesn’t necessarily reflect the potential knowledge they have acquired. Given the mentioned circumstances, a standardized test should be applied to ensure that the right set of knowledge and practices have indeed been utilized by the potential mentor figure.
Since the software development industry is ever evolving, certain educational materials should be prioritized on a relatively frequent interval. It doesn’t make all too much sense in learning about critical topics from decades ago in an environment that has perhaps produced a more streamlined and modern solution. A yearly planning and evaluation of existing tests is probably a good start.
Communicative
This one is pretty much self explanatory. Don’t let people with issues with human interaction and communication be mentors. If a mentor cannot properly communicate thoughts and adapt to situations driven by a colorful portfolio of mentees, they shouldn’t be in charge of shaping and guiding company personnel that depend on elaborative answers and sharp communication skills. Short, “Yes” and “No” answers to most questions have no place in a mentorship environment.
Not everything can be easily explained or effectively communicated, nor should it be expected from a mentor to do so. Cracks can happen and it’s unrealistic to expect that none would manifest themselves over time. Dealing effectively and timely on any communication bottlenecks takes time and knowledge and an exercise in patience should be accounted for.
Pair programming
Where communication skills are lacking, practical knowledge comes to shine. Pair programming presents one of the more effective tools for passing and solidifying existing knowledge. It’s also one of the more challenging for one to get used to. A good approach would be to look at pair programming as a game of sorts (ping pong comes to mind…) where the engaging parties play off each other rather than against each other.
Pair programming is also a highly effective project onboarding solution that can, over time, break the dependency chains for relying on a single or few team members for doing a task. Every participant in pair programming has a very strong project knowledge starting point from which they can either complete a set of tasks all by themselves or provide onboarding knowledge to other team members. The team hierarchy becomes relatively more flat with every team member potentially having the knowledge to temporarily fill in for another team member.
Similar to code review sessions, it’s encouraged for team members from different project areas to engage in pair programming with the benefits aligning with the statement we previously mentioned in this paragraph. Frontend and backend developers having mutual pair programming sessions, for example.
Accountability
Having a sense of accountability and taking personal responsibility if or when something goes south is perhaps one of the strongest traits a mentor can possess.
One of the hardest things to do in our personal and professional lives is to raise a hand, stand up and admit accountability for making a mistake or a wrongful judgment call. The price to pay can be substantial and depending on a situation, potentially job threatening. Although scary, one should not run away from it and deal with it as soon as possible.
It’s not just the encouraging act of raising ones hand, but also the ability to take in whatever consequences there might be for the things we had set out to do but for whatever reason those things are left uncompleted. Building on top of what we said in the previous paragraphs, it’s immeasurable how much impact this act can have on the impressionable minds of mentees, fellow team members and other people surrounding us. It sends a clear message that one shouldn’t avoid/postpone anything that comes as a result of wrongful decision making and solidifies the professional relationships between people by increasing the confidence levels in each other. If by any chance the situation arises, saying: ”I was wrong for such and such thing. I didn’t have the complete oversight of the problem at hand. I learned a lot from this experience, the mistake(s) I made and from this point onward I’ll try to mitigate the possibility of the error occurring in the future.” — is the first step onto the path of accountability.
Tutorials and Tutorial hell
I want to preface this section with the notion that not all tutorials and guides are made the same. While many of them are very superficial with carefully dancing around important topics, there are others that go extremely in-depth about a subject and that’s directly tied to the value of said tutorials.
Many online tutorials are like commercials. They are there to give us the bare minimum of knowledge about a product in the shortest amount of time. As such they are extremely addictive. The only thing not included in those tutorials is an extensive list of ‘potential side effects’ at the very end. Chaining tutorials is also called ‘tutorial hell’ because it’s hard to escape the information overload they provide. Lets not fool ourselves, information can be very addictive. Without dedicating time to experiment with the tutorial teachings on our own, maybe on a new project, we risk losing that knowledge very fast. The knowledge curve, without enforcement learning, fades rather quickly. A bad example is to go to online tutorials
We all learn in a different way. Someone is more inclined to enforce visual learning with video materials being a go-to solution. Others learn by example or by diving ‘head-first’ into a new field or technology and dealing with problems as they arrive. The point is, everyone has their own way of learning. A good mentor figure should prioritize and adapt to a mentee’s learning preferences and strengths. Yes, it can be very challenging if a mentor has to balance multiple mentees with totally different learning preferences, but that’s just it! No one ever said it was an easy job to do. And in this day and age it can be vastly overlooked with some other aspects of the software development process being put forward into the spotlight. There’s a reason why there are numerous articles and publications that mention optimal classroom sizes and how many pupils should one tutor at a given time. While the promise of 1 on 1 teachings seems like a good idea, that might not be the ideal scenario, especially in the software development industry. Many companies can’t afford dedicated mentors for each of their junior-level employees and even if they can afford it, it can lead to counterproductive results. “How so?” — you might ask. Well, being a mentor figure for one specific pupil and their mindset leads one to become subject to tunnel vision and developing mentoring skills that are tailored to one specific mindset with losing the oversight of other possible ways for passing on valuable knowledge and when the day comes to mentor a new mentee, the mentor simply has no valuable skills in dealing with a new set of challenges. Same thing applies with learning one technology over and over again and becoming a true expert in that particular field and if a time comes to migrate to a different technology field, a large subset of the previously gained knowledge provides little to no use.
Not wanting everything to be abstract, for a use-case basis, my first steps into a mentor role were driven by the knowledge of how I pictured the “idea”’ mentor figure based on various scenarios and situations that I’ve dealt with over the years in the industry. And that’s a great start, having a mental picture of what your goal is as a mentor. What are the topics you would’ve liked for someone to have thought you of? What are the teaching approaches you’ve seen somewhere that might lead to results you are aiming for? What are the topics and foundation bricks that you’ve gathered over the years and feel like that they are essential for building a career in the software development industry? Those are all good starting points. From there onward, you’ll learn as you go and grow into the role.
Should you accept a mentor role if provided with the choice? It depends, doesn’t it? Everything that I’ve mentioned previously should factor into that decision. If you don’t see yourself as a dedicated mentor figure, just step aside. You could do more harm than help if you take the wrong approach with dealing with people that are eager to take their first steps into a new world. And if you don’t have a voice in the matter, basically no choice, you should be honest and upfront with the prospect that you’re not the ideal candidate for that position and that you’ll do the best to your knowledge to deal with that fact. Who knows, maybe you’ll grow into that role and in the end actually become quite good at it. But, don’t forget, be honest with your mentees and that you are learning about your role as they learn about a given topic from you.
One thing to note, don’t teach if you’re afraid that your pupils might overtake you at some point in time and take your job. That’s not the right mindset to go into a mentor role to being with. If that’s the case, just move on from the role. Having that kind of an ego is totally fine, but having those kind of mental obstacles and barricades, limit you from reaching the tutoring heights you could.
Mentoring for general purpose or production
Here’s where true experience can come forward. It’s easy to get lost in the most common topics in a development environment and steer the focus onto them, but like so many experienced and seasoned developers can tell us, that’s only the beginning and far from any idea what a production environment requires. In production scenarios, it is not enough just to get a project into the done phase, the final stretch needs to be completed too. In today’s markets, in order to stay competitive, one has to go beyond the core concept for an idea and expand around that. There’s a whole ceremony that goes into pushing a product from a developer to a production stage. A product might have the best solution algorithm implemented, but if that solution is presented in a sub-professional way, it will be incredibly difficult to sell that product to someone. Testing for scale comes to mind. How a product behaves on 100, 1000 or 100000 instances. If a problem arises, how many clients will be impacted during a window of time needed to deploy a patched version of the product? Will all of the clients receive the update simultaneously or not? Those are just snippets from a pool of examples for potential production-related challenges.
Mentoring for general purpose covers the generic and hypothetical scenarios during the development phase. Providing the bare necessities needed to keep the progression status bar inching forward, if you will. The scope for this kind of mentorship lacks the laser-focused precision of the production one. More time sensitive domains usually require the more precise production approach and at an introductory level, the more generalized mentoring approach can be applied to.
Not tied to any specific rule, depending on the topic, it’s often recommended to start off the mentoring process with the general purpose objectivity and slowly move into a more narrowed scope of production level teachings.
Two way assessments
Putting a focus on mentor assessment with constant feedback from the mentee drives a successful collaboration between the two. Either one should be allowed to state their thoughts and review the progression of their mutual, professional relationship on regular intervals. The intervals can be initially defined as starting guidelines and changed over time with more focus on shorter feedback loops.
There are certain expectations of both parties involved for each other. One can expect a certain level of progression in between two checkpoint intervals. Clear definitions of what is expected of each other should be mentioned as early on as possible, if possible, at the beginning of every assessment period. A mentor should request a performance review from all of their mentees with an emphasis on honest thoughts and opinions in order to provide a chance for professional growth and self improvement.
A note of caution of constant pursuit of self-improvement should be, at least, mentioned at this point. Putting a constant effort and strain into professional growth for every aspect can lead to burnout scenarios and we certainly don’t want those. Being realistic and intermediate with the feedback inputs we receive is the key to a successful long-term professional development.
Third party check ins
We finally come to, perhaps, a singular answer to the title question in this article. Everything can progress at an excellent pace. The mentee is learning and advancing nicely. The mentor is happy with the overall progression and proudly stands by the teachings learned in the previous period. But, what if not everything is as good as it might seem on the first look? How can we evaluate the progression and success of a teaching approach? By the results provided? Of course, that’s one measure of success. But, who does the measuring? The company? The manager? Or is there someone else?
Preferably, there would be a dedicated role assigned to a person that will oversee the mentorship program. While many companies implement performance review programs, by default the role of mentorship performance assessor is assigned to a manager role and it, kinda, makes sense. Measuring a mentees progression on a, let’s say, quarterly basis can provide enough information to form an evaluation score. If there are expected timelines for a mentee to reach a given level of knowledge, that can be measured. Those timelines are also directly tied to the mentor figure. If at the end of a performance review, the mentee doesn’t reach the set goals, that can be directly tied to the mentor as well? In many cases, yes it can. There are certain goals and they are meant to be reached. Are those goals realistic, that’s a whole other subject that we can leave for some other time. If many of the mentees reach the performance goals, is it alright to presume that the mentor is doing a good job? For the company and for those goals, that is indeed the case. And if not? It’s time to assert the mentor figure’s approach in the mentoring process.
Those are all “happy” paths where there is such a role as the mentorship overseer, but where one is nowhere to be found, we start to see the cracks in the whole process. What if the mentor is doing a terrible job and the performance results of the mentee is strictly based on the fact that the mentee has taken the problem into their own hands and progressed on their own merits. Should the mentor be rewarded in those kinds of situations? From the company’s perspective,yes, but from the mentor’s perspective… Well, you can guess the answer to that one.
What goes into overseeing the mentorship process? A curriculum would be a start, wouldn’t it be? A plan and program tailored around a mentee with clearly set goals. The program would be based on a mixture of the companies needs and the level of knowledge and abilities of the mentee. That’s why guidelines with checkpoints are needed. The content in between those lines should be tailored to the mentees specifics. The plan can serve as a checklist for the mentorship overseer to ask both the mentor and mentee at the performance review. Sitting in on a whole session of mentorship is also an option, but can lead to false-positive results where all parties included would give their best to shine. Formulating a questionnaire with a few questions with the opportunity for everyone included in the questionnaire to form their unbiased opinions. Arranging personalized 1 on 1 sessions where needed can lead to valuable shortening of performance feedback loops and to quickly address any potential bottlenecks.
Who would be an ideal candidate for the overseer role? I’m not here to give a definitive answer to that question. I simply lack the skills and the knowledge to form that kind of an answer. Like everything else, I can only give only my “two cents” and perhaps suggest that the role can be assigned to someone who has a previous successful background as a good mentor figure with the necessary drive for self improvement and the hunger to learn more about the process as it advances in both the software development industry and in general. Someone with a static mindset that is firmly anchored in past teachings is bound to produce legacy knowledge in an industry where progression moves at a rapid pace and where today’s knowledge means a bit less tomorrow.
Final thoughts
At this point, if you followed any of my previous articles, you know that this is the part where I would ask for your opinions on the subject matter. Are you in a mentorship program right now? What interesting approaches have you learned so far? Are you a mentor? I’m eager to hear out your thoughts and approaches in providing a very valuable role in someone’s career and personal development.
We are all here to improve ourselves and incite development growth.
