In some fewer words I would say that the force of mentorship should not exceed the strength of pushing a canoe into a river.
You're not there to set hurdles. You're there to recognize when someone is fighting the upstream flow or have embanked themselves in temporary enlightenment.
I disagree with the definition of the mentoring and coaching from the article.
Maybe the author definition is from sports, but outside it here is how I see (and how many of people that I encountered so far see) the difference between coach and mentor:
In a coaching relationship the coache sets the agenda not the coach. The coach is more backseat than a mentor. The coach is there to walk along the coachee on the coachee path while providing guidance when asked, usually in the form of guiding questions or helping navigate various points of views or helping go through decision frameworks.
In a mentor relationship the mentor sets the agenda together with the mentee. A mentor has a more active role in the agenda providing active guidance and feedforward. The mentor and the mentee walk together on a path they both agreed on.
As an example:
If I would go to a coach and say ask about should I learn Elixir or not taking into consideration my Ruby background, then the coach will not answer yes or not. But should help me discover for myself the answer. It will usually help me look at this question from various points of view or can provide a decision framework, but the answers (or the content of my answers) will always be mine or my own discovery. So they will not state "Elixir is like Ruby" or "Elixir is not like Ruby" but they might ask "How can you assess if Elixir is like Ruby?" or "What is the smallest project that you can create to see if you like Elixir".
If I would go to a mentor and ask about should I learn Elixir I expect them to tell me pro and cons of Elixir and also have an opinion about if Elixir is really similar with Ruby or not and even express their preference for this programming language or the other.
So I choose to go to a mentor or coach depending on what outcome I want to have and what experience they have.
PS: Please take the Elixir and Ruby just as an example of a technical matter to be discussed with a coach or mentor.
This articulated for me one of my biggest frustrations with traditional 1:1s with managers I've had throughout my career: by these people I want to be coached, not mentored.
Most 1:1s have been driven by me, at the explicit behest of the manager. "I'm here for you" and "this is your time" are/were common phrases. I found this particularly annoying as a new grad when I really didn't know what I didn't know and just wasn't getting a lot of mileage out of those conversations.
The biggest thing I've learned when being in (loose) teacher or mentor relationships is NOT to push someone to do what I think makes the most sense or that I think strongly is the easiest way to go. Instead the best thing to truly help someone out is to encourage them to do what they WANT to do.
The reason is because even if there truly is a simpler way, it isn't always simpler for someone in their current position based on their current biases/experience/knowledge/etc. But what you WANT to do is a really powerful motivator and the most important thing is that you keep trying things and get better eventually.
Good article.
In my personal experience a good mentor will never patronize but will still manage to convey their, usually higher, expectations for kind and quality of your work.
The best mentors I've had were also extremely good at receiving and processing feedback themselves because they honestly loved learning and wanted to be better as much as I did.
I'd had number of mentors, and myself almost a decade of experience teaching technical classes and 1:1 private lessons before I got into mentoring other SDEs at work and was amazed by how much I learned even just from first few relationships.
Coaching and mentoring really are so different.
I have definitely seen organizations where either the culture or the "climate" all but prevented effective mentor / mentee relationships no matter the effort. Really don't miss working at those places, probably the most burned out I had ever been in my career.
Unrelated rant, and not saying this is the case here I'm sure it is not from reading the authors blog. However, anyone notice how 4/5 developers describe themselves as mentors? I've intereviwed so many people who describe themselves as mentors yet could not answer fizzbuzz
One thing people forget: let your mentee fail. Don’t bring the business down, of course. But do let them fail — there are good lessons to be learned and failure is a great way to do so with an emotional impact that lasts much longer than an intellectual one.
> In mentoring relationships, usually the mentee sets the agenda. In a coaching relationship, usually the coach sets the agenda... Code review is a pervasive example of coaching being confused with mentoring.
To indulge in a bit of naked self-interest here: a few people have mentioned paying for coaching or mentoring. How does that work, did you personally pay or did your company pay, and what was the hourly rate if I can ask? I'm wondering if it is a reasonable angle for some of us old-timers to get into. I'd have to charge an amount comparable to software consulting, and I'd expect most people to not be willing to pay that out of pocket, but maybe I misunderestimate (sic) this crowd.
Weirdly, in one job interview they asked if I was willing to mentor junior devs. I said yes, they hired me, but the subject never came up after that. In another, the topic never came up at all, nobody approached me for mentoring at the job, but my management later hassled me about missing their expectations about it.
The article is generally pretty good.
After being an independent contractor (software engineer) for a decade I am now a full time employee and in my first formal mentor-mentee relationship. I would love to hear about positive experiences people have had from mentoring as I’m still feeling out the relationship and wondering where it can go.
> Some people read histories, stories, case studies, and so on to learn from the experiences of others. Other’s don’t.
An interesting observation, and while you could say it's less efficient if you're the latter type it seems there are other benefits.
In my experience, one fast and practical way, is to assign issues, from small to big.
Mentoring and coaching terms are a bit too one-way for my liking. So I’ve always avoided that terminology in favour of more peer to peer metaphors.
While I may have more flying hours in some topics of life or work, even a younger and/or less experienced person in some ways, can teach me something in other ways.
Building each other up makes for very rewarding bilateral relationship.
someone just made this https://old.reddit.com/r/software_mentors/
Not only soft skills, hard skills at the high level also hard to come by.
One thing I sometimes point out to software engineers Im tasked with mentoring at work is the importance of showing other engineers that you care about the code and the questions you're asking via slack etc by proof reading what you write and reviewing your own code before reaching out to others for help. The frustration of reading ia garbled slack message or pulling over to look at a code snippet and realizing the person didn't even look over it themselves is real and has real negative consequences in terms of professional perception.
Like when someone misspells radical candor in the second sentence of a blog post about mentoring.
Seriously though, everybody makes mistakes but when I do slip up like this I don't expect people to engage with what I'm writing. And I do think proof reading is an incredibly important skill for new and experienced software engineers.
[edit] I just noticed the author is a staff engineer at MongoDB. He can misspell whatever he wants. I recant my sassiness.
> Like a lot of soft skills, we’re rarely taught how to mentor
^ This is one of the first lines in the article. If I had to guess I'd say most people here spend a relatively small amount of time learning about how to do their job vs actually doing it.
For me this is a good reminder that actively/intentionally investing a couple hours per week in learning about how to do things - technical or not - and evaluating myself will probably have a higher ROI than spending those hours doing the thing
This reminds me of some of the ideas discussed in this post [0] from a few days ago.
[0] https://news.ycombinator.com/item?id=29692029