"I will teach you to be rich!"
"Everyone is a coach nowadays!"
"I'm looking for mentorship in sorting my socks."
"I'm not your guru!"
"No, I'm not a freelancer, I'm a consultant."
There are so many terms trying to explain training and helping relationships between human beings. With many terms comes confusion and misuse. What if there was a committee that would decide about the proper usage of those terms? How many mentees would be saved from being coached? How many minutes of podcasts could be unwasted trying to figure out the right terms to use?
Wait no longer. And don't wait for a committee. You can have your own definition right now.
Below is my unscientific digest about the differences between these terms so we can have a common basis for talking about them and you can have some inspiration for your own definition. The digest is based on conversations I had and heard, as well as the knowledge I gained from literature, helping others, and being helped. I'm specifically looking at this vocabulary within the scope of tech careers and software projects. In other fields, such as sports, this might not apply similarly.
Relationships between people are complex, nuanced, and might vary strongly. The lines can be blurry. Also, in one single relationship, elements of every term can contribute to solving the student's problem. Still, below are some "stereotypical" blueprints for the terms, with a few examples from the tech world.
Mentoring
The apprentice has a chosen path that they want to go. A mentor is someone who has lived through this path, physically and mentally, so they know the ins and outs of how it can go. A mentor sees a roadmap for the student. They offer advice and often hands-on help to deal with the challenges and barriers on the way. The student has a great deal of intrinsic motivation and drive. The mentor is intensely interested in following the student's path and learning from their results. It's a 2-way relationship with significant benefits to both sides.
Example: An aspiring computer science professor is collaborating with a professor whose work he admires. The student doesn't miss opportunities to help the professor build the technical side of his projects. The professor also takes an interest in his apprentice's work and shows him the steps to publish exceptional research.
NOT mentoring: A company creates a "mentorship program" where new or more junior software engineering employees get randomly matched with more senior employees. The senior folks show up to regular calls to see whether the juniors have questions. Since they work on different projects or vastly different parts of one project, there is often not much to discuss.
I'm not saying that this can't work with highly driven individuals on both sides, but in the real world most of the time, those are just occasional calls that are coaching attempts at best. At worst, both parties see the whole thing as a chore and waste of time.
Coaching
The student has a big challenge to overcome. A coach is often a professionally trained person who asks the right questions, installs productive mindsets and creates thoughtful prompts for the student to find their solutions to the problem. Of course, some coaching might include practical exercises and help, so the lines between mentoring are blurry. Coaches might have experience with the student's challenge, but an exceptional coach will help a student even without prior experience with their exact challenge. The coach provides a service to the student to solve a particular challenge. So, often these relationships are more transactional.
Example: An introverted engineer hires a mindset coach to help her prepare for her first conference talk at a prestigious tech conference.
NOT coaching: A career switcher asks a software engineer to help her get a job in tech. They have regular sessions to code on her sample projects and polish her application system. It looks like the software engineer is mentoring the career switcher on their path.
Also, NOT group coaching: A guy gets on regular calls with coding bootcamp students to explain topics in detailed hour-long presentations mixed with practical exercises. The more structured these sessions are, the more they become teaching.
Teaching
A student wants to learn a particular skill. The teacher provides a structured program (lessons, workshops, and such) to effectively instill the skill into the student's mind in the long term. After the program is over, the teaching relationship usually ends or goes to the next teaching step. At the end of the program, there might be a certification or another form of official acknowledgment of the student's achievement.
Example: The API team sets up weekly lessons to help the domain teams ship better APIs as part of their development. The lessons introduce a common problem and propose a solution. They build on each other and are recorded, making them a bit like a video course.
NOT teaching: The API team sets up weekly lunch-and-learns where everyone can join and ask questions about API stuff. I guess you could call this a punctual, short-term group mentoring offer.
Consulting
Someone, often a company or enterprise, seeks solutions for their business problems. The consultant gives actionable advice and proposes solution plans. The consultant might end up implementing the solutions. The consultant is liable for the advice they give and the work they do. They act in the best interest of the company.
Example: A client hires a consultant to help them automate a boring manual but valuable process in their marketing department. The consultant dives deep into the client's problem and finds the best solution, which he then presents to the client in a consulting session. After the session, their collaboration might continue in a way that the consultant implements the solution, helps them implement it, or consults them again on the same or a different topic in the future.
NOT consulting: The consultant has been incorporated into a company's day-to-day 9-to-5 operations for years. This is called employment.
Here are more examples of the terminology being packaged up into my own training offerings: https://richstone.io/helping-you/
There is a saying in software engineering that "naming is hard". It's even harder when you just have a vague image of the term that you are using for the naming. I hope this article put some images to work into your head, so you can now be your own committee and reason more clearly about the work you are doing to help others.
