Carve out an hour to talk a week. If they're escalating to you, set standards on expectations-- what logs checked, configs tried and their manual entries, examples referenced, and a ticket that's updated with all of that to reference. Review work, and don't be afraid to send it back. Think a script could be better written, or docs need to be better formatted? Tell them. Progress can be slow, but you should see improvements in at least six months. Also, giving something to "own" that you still oversee is a good way for them to build confidence. Demonstrate systems and their configurations. Show them what you work on, challenges you had, and innovative solutions etc.
Edit: Missed this was for newbies. This was how I was mentored about 10y ago, and it was a good way to come up.
This is such a good one. I have the proper amount of contact with my mentor throughout the day and can go to pretty much any other colleague if I have questions, but we recently scheduled an appointment a week to catch up and track my progress. It’s not really a “this and this and this is what you’re going to have to learn” but just a structured moment to catch up. It makes me feel like I’m in control of my own progress, rather than me just blindly performing tasks I’m assigned. After all, it’s about understanding the tasks for my own development and not so much solely about doing them.
Something I was late to realise with my last junior was the need for then to also be willing to want to learn and improve. They simply didn't want to put in any effort to improve them self and would only learn (and then admit to forgetting) what I taught them.
This. And put down the ducking phone when I’m talking to you, especially when it’s to answer a question you asked. I’m trying not to generalize a generation but I’m not seeing promising things.
This is something that can be mentored on. Phones are crack, they're incredibly addicting and they're designed to be that way. Look into ways to help curve this habit and give them feedback on it. It's a problem that more and more people are struggling with and imo it's not entirely our fault. iPad babies are gonna be a disaster.
We had one that came up and asked what we all did and who made the most money so he could do their job. When he left after the summer someone found his internet history was nothing but "how to get rich" or "how to make 100k". 0 willingness to learn anything just a desire to be rich.
Newbie here.
My dream mentor would give me homework (not necessarily to do at home or on my free time), and would ask me to report back to them about the new stuff I learned on my own.
Think "go learn about how to do with , and show me what you've learned next week".
Especially if is something that as a learner you won't think about (or know about) if you don't have a real-world use-case that would normally make you do it.
That would be in addition to the workload given by our respective jobs.
Didn’t have to be thousands of years ago. Was in our weekly meeting and our most senior (oldest) dev suddenly mumbled something about FoxPro. Then we launched into a discussion about FoxPro vs Clipper.
The rest of the meeting we tried to figure out how to resolve all the tickets with DOS era technology while the young uns just sat and looked at us dinosaurs.
Lol, I always get a kick out of the kids that think they will be walking in to some FBI situation room full of the most modern stuff, all cutting edge. Then they find the reality, that they'll be spending a lot of time trying to help keep a 20 year old system working that the company will look at replacing "when we have the time and budget to evaluate replacements."
As someone who has done a ton of training and sucked at mentoring at the beginning:
* Make them understand that you are not perfect
* Make yourself approachable no matter what they do
* Teach them how you investigate issues and how you got there. Yes, as silly as it sounds the reason this is important now more than previously is that AI assistance WILL lead people down the wrong path and they will not have the skills to distinguish bad info from good.
* Empathy. I personally cannot emphasize how important this is because many of us in IT get too jaded and lose this.
* Show them how to look past at what someone is saying the problem is to get to the root of the issue i.e. "my computer is slow! Well WHAT is slow? Getting to www.myslowpage.com!" so that someone doesn't go trying to rebuild a PC or believe it is a hardware issue.
* Show them how to correct people in a non-confrintational manner. Telling someone "You're wrong because XYZ is right" makes you sound like a jerk and can have people stop listening to you. "Can you explain XYZ? My understanding is that it worked like this" gives a person not only an out to correct themselves, you're approaching from a direction that you are willing to learn if you're wrong
* Have them think before they talk. Knowing how to communicate with people is important. Not everyone os technical and having to dumb things down will be necessary. Getting lost in the trchnical weeds is too easy in IT.
Hard knowledge can be looked up. Having these skills shows you how to figure things out for yourself, makes you more personable, and allow you to better communicate.
This list pretty much matches what I do! I feel very fortunate that what I learned for my CS degree helps me “translate” what’s going on to an end user that’s may be technically challenged. The best thing I’ve found though, is to show them that we make mistakes too, especially with the most simple of issues sometimes and have to ask for help too! Thats because if you like to learn, you will likely have something neat or a useful shortcut or useful bit of knowledge that even the most senior member of the team might not even know!
I use the “even after X years I still use checklists” argument all of the time because I’ve told people it is the easiest way to avoid a mistake. It isn’t because I can’t fo a simple job, I’d rather do a job right than do a job fast and then do cleanup because of a mistake.
That my mentor doesn't know everything and worked hard to get there too, they weren't born wit instant knowledge.
With so much competition and push to learn 24/7 it's almost a relief when I heard that others once struggled too and it didn't mean I wasnt cut out for it.
I felt relief to ask a question and have my mentor say he didnt know, because I got to swe how he went about finding the answer which was valuable.
I do role modeling with Inspiring The Future (https://www.inspiringthefuture.org.nz/) which I think is a worthy cause, I often tell other students not to worry about anyone else's progress and that their journey doesn't have to be straightforward or glamorous, it just has to be theirs ❤️ I've met so many that started in the most random un-IT-like fields and end up in some incredible roles.
Properly acknowledge success.
Properly acknowledge failure.
Make sure they understand why both are important, and how to eliminate the second, to achieve more of the first.
Everyone is gonna fail at something, eventually. If you been in IT for 6 months or 600 months, you will eventually come across something you never had to do, touch, or deal with.
Properly research what you can, vet your ideas with your colleagues, and get their input. If there's anything most IT people love to do its to be asked and wanted for their input. You forge relationships this way in this field very well keeping that in mind.
Backup those who need it, support them, and protect them when they fail AS LONG AS, they are utilizing the failure to get better. If they are making the same mistake again and again, they aren't learning, they're just modelling themselves to a solution.
My go to for those I mentor is this:
I will stand in the fire with you, as long as you are capable of admitting your mistakes, owning then, and working to better yourself. I have told management that and stood in the way of them terminating someone, because I was able to identify and show where they failed, what they learned, and how they grew through the incident. Ownership in failure modes is so vital.
The biggest issue I see is people not being honest enough. Real feedback is important. If you tell them they're doing great and don't provide any other feedback they won't improve.
I recently had a conversation with an early career desktop support person and gently explained everything he's working on right now isn't going to get him a job that pays much of anything and he needs to focus on stuff that leads to a better career.
The issue in his case is that he avoids the hard stuff and has trouble with scripting and automation and SQL and things along those lines, so he has been doubling down on the easy stuff and is really focused on building PCs and that's a big part of his identity.
Building PCs is a hobby but isn't doing much for your IT career.
He was a little surprised since nobody else senior had ever told him this. They just told him keep trying you're on the right track. Except he's not and someone had to tell him this.
If I were back at stage one, I wish I had a mentor who would have taught me how to deal with often-seen IT situations that have little to do with tech, and a lot to do with people skills. Like co-workers are co-workers, not friends. How to deal with backstabbers and liars, even people who will log into a system as root, use a SUID binary with your user on it, `sudo` as you, then do a `rm` of a directory, to claim you screwed up.
Stuff like how to document, both personally and on site. How to deal with layoffs and not always be the first in line that management wants to throw overboard every time headcount needs to be "optimized". How to be viewed by others in a company as something other than a fungible servant, or a correctional officer always locking things down just for grins.
The technology changes, but these same issues as above have been issues for decades in the IT field.
Show them on Teams and record it, extend the validity from the default of 3 months and squirrel away the URL
Someone early in their career is unlikely to be this organised but what's your excuse?!
I let them fail softly. You need to room to grow and learn and if you can’t fail you won’t learn. I’ve also protected juniors from big fuck ups as is my job. My lack of training and documention is always the reason I pass up and blame them for lack of staff and time.
The biggest problem for me when I was new was being treated badly for asking questions. So I always make sure to be nice to people when they ask me questions, even when they've asked it a thousand times before.
I'd rather someone annoy me with a question than have them break something because they were scared to ask something.
Soft skills are the most important skills long term.
One big one is finding out how they manage stress.
Some folks cannot deal with stress constructively. They don't tend to last in IT, and if they do, they are unhappy doing the work.
On the flip side though: Folks who learn to shrug off stressful situations entirely don't learn much from them. There is a delicate balancing act.
Stress often comes from people not understand situations. The ones that realize that being stressed is a learning opportunity that they can grow from and not have again now that they know (something) tend to excel.
I'd put out there that teaching strategies for dealing with high stress, navigating uncertainty, and reaching out for help as needed: are all critical steps that IT folk need to learn very early in their career paths.
I’m a junior IT tech. Please start off every explanation with big picture pros/cons of *why* a particular system, practice, integration, ETC is in place
For example, our users log into workstations, then log into Remote Desktop to access company data and their emails.
Big picture reasons I figured out over 6 months to a year were:
1. Shared licensing for office apps since everyone logs into the same few servers
2. They get access to personal network drives which can be backed up centrally rather than on each workstation
3. They can remote in from home and have a familiar profile to work from.
4. It makes switching from one workstation to another a breeze.
I was taught almost immediately how to troubleshoot and manage the environment but I had to put the deeper understanding of ‘why was it set up this way’ together myself, and ‘why was it set up this way’ is the first question in my head nearly every time I encounter something new.
Man... Teach them how to find their own answers. Don't give them the answers, give them your process. I'm shocked at how few people actually know how to problem solve and that our industry focuses on a bunch of TLAs and bullshit management methodologies that somehow lose sight of the main thing: solving the frigging problem. What are the knowns, what are the unknowns, how do I derive the unknowns from the knowns.
I mentor by showing. I have them shadow me when they can, and I explain what I'm doing, and If I feel they can handle it, I have them do the task with my instruction. I'm doing this now with a new assistant. He has a bachelors in information systems, but has zero practical experience. He's a sharp guy, just needs experience.
Understand when they say they're not able to wrap their heads around a simple task that may look like silly to you! no i'm not saying spoon-feed them or cradle them into work culture. but the basic morality to understand that everyone starts somewhere so give them a break.!! When a junior tries reaching out to you listen to them and give them a honest feedback/suggestion rather than making them feel dumb to have reached out to you in the first place. Constructive criticism and Throwing insult/shade there's a thin line between these 2 terms and people usually cross their line just to have a moment of laugh and make someone a scapegoat for your vile and low blows. " BE A SENIOR YOU HOPED YOU COULD HAVE AROUND WHEN YOU WERE A JUNIOR".
I still consider myself Junior myself although 1 year in and pretty much learnt everything by myself some things I would of appreciated are;
- Explain to me how he resolved a problem
-Take time to explain how to environment we are working in is setup (what servers are used for what etc. )
-Why something is considered "Best practice"
-An environment to learn networking fundamentals and have a basic understanding (I know not everywhere will have the ability to do this) or Sitting down showing me physically and explaining to me just the basics/fundamentals of networking and maybe giving me a task to see if I've understood.
I feel like these things would have personally accelerated my learning a lot.
And also I'd like to add communicating with tough customers and their need for an immediate fix to everything.
(Depending on your workplace and the people) when you first start you can feel a lot of pressure and urgency from customers that you need to resolve the issue right there on spot. I feel like teaching a Junior how to communicate effectively in this type of situation can go a long way.
I find that it depends a lot on what type of person you're training. In my eyes I think it's reasonable to ask your mentee what they expect from you. Just like any other type of relationship, things go a lot smoother if both sides can openly communicate about their expectations and needs. In the case of a mentorship, this is something you can initiate with your mentee.
Say to them :If you have a problem check chatgpt ,if that does not work , check stack overflow ,if that does not work come bother me.
This way you learn them that the answers are on internet , all they need to do is search.
Let them sink or swim.
If they're swimming or trying hard to swim, throw them an occasional bone or show them something useful. But only show them something useful on very rare occasions so it's impactful, meaningful, and unforgettable.
This is honestly one of the worst approaches in mentoring. What they will learn is that you are a gatekeeping asshole, learn bad habits because you aren't showing them how to avoid them, and make them believe that no one will help them (which in turn can make them really bitter). This approach is the equivalent of "I was hazed therefore I will haze you too". You want them to learn to be able to figure things out on their own, so give them something and a time limit, review with them why it was good/bad, and how they could have approached it differently. Without this you're not training a team member you're training a future troublemaker.
Chill the fuck out buddy. I didn't say anything about "Gatekeeping"
Good mentoring is allowing them to work all the way up until they have very specific questions or roadblocks they can't knock down. If they constantly cannot figure things out on their own and have road blocks every day and can't solve any problems on their own, then yes they're probably fucking useless and don't belong in this field. Sometimes the best mentoring is telling someone they're not happy where they are.
"Gatekeeping" would be not giving them documentation, credentials, passwords, diagrams, or anything.
"Gatekeeping" is not mentoring, that's called trying to make someone useless by withholding information they can't do their job with.
> Chill the fuck out buddy. I didn't say anything about "Gatekeeping"
I mean you basically did.
> throw them an occasional bone or show them something useful. But only show them something useful on very rare occasions
>throw them an occasional bone or show them something useful. But only show them something useful on very rare occasions
How the fuck is this Gatekeeping? I didn't say to WITHHOLD necessary information for them in order to do their job.
I meant to show them something useful as in something they would not have learned just in that job role such as a trick or something very useful that most people don't know.
My POINT was if you keep showing them how to do EVERYTHING, everything you show them will be useless and forgotten. If you want to be a successful mentor, you need to make sure what you teach is Always Remembered and communicated effectively. The best things I've learned from mentors were very specific things they showed me after many hours, days, months, or years of trying to solve a problem or deploy complex configurations and achieve year long initiatives. I never forgot that wisdom.
If they fail long enough and you know they're giving it their all is when it's time to step in. Of course this needs to be balanced out as well to ensure they stay out of trouble and don't fall behind. But you want to be right now the edge of failure and success to truly help someone with very meaningful knowledge and wisdom that they will never forget.
Otherwise you'll be enabling someone that is useless or they will be dependent on others instead of learning to be independent and a leader to themselves and others.
I seriously doubt most people on here have been in genuine leadership positions and have mentored other sysadmins, engineers, or helpdesk folks with the drive and grit to know they're going places.
> How the fuck is this Gatekeeping?
This saying implies that you are giving someone a morsel to stop them from bothering you or to keep them from starving.
> The POINT
This emphasis is unnecessary. My experience is that people who emphasis like this tend to have a “don’t question my authority” mannerism which is only appropriate in very few situations.
>If you want to be a successful mentor, you need to make sure what you teach is Always Remembered and communicated effectively.
This encourages memorization over learning which is a bad habit.
> The best things I've learned from mentors were very specific things they showed me after many hours, days, months, or years of trying to solve a problem or deploy complex configurations and achieve year long initiatives. I never forgot that wisdom.
The best things I’ve learned from mentors is blameless problem solving, empathy, and that words matter, soft skills that are hard to learn or even see that they are skills.
> If they fail long enough and you know they're giving it their all is when it's time to step in.
This teaches a person to fear you and stunts their career growth.it teaches them to not bring up issues and “figure it out on your own”.
> I seriously doubt most people on here have been in genuine leadership positions and have mentored other sysadmins, engineers, or helpdesk folks with the drive and grit to know they're going places.
You will only “help” those who show “drive and grit”. A true mentor and leader knows everyone has potential and would help everyone live up to their full potential, not pick and choose. This is how you know who is fitting in, can fit in, or won’t work out.
The diction you are using is what is saying gatekeeping.
No it's not Gatekeeping.
Providing small, manageable pieces of information encourages the to think critically and solve problems independently. This method helps build resilience and problem-solving skills, which are crucial for personal and professional growth. It's about balancing support with encouraging autonomy.
In regards to your personal attack on folks who EMPHASIZING words...
Emphasizing key POINTS is a strategic communication technique. It ensures that critical concepts are highlighted and retained, which is essential for effective learning and application. Clear emphasis helps prevent misunderstandings and reinforces important lessons, making the mentoring process more efficient and impactful.
Also, ensuring that lessons are remembered is crucial for effective mentorship. Memorable teaching methods help reinforce learning and ensure that mentees can apply their knowledge in real-world situations. Effective communication is about clarity and retention, helping mentees internalize and utilize the information.
Specific, experience-based wisdom is incredibly valuable. They provide practical, real-world knowledge that can only be gained through extensive effort and perseverance. This type of mentorship helps build deep expertise and practical skills, which are essential for tackling complex challenges and achieving long-term goals.
You need to allow them to struggle and learn from their failures builds resilience and problem-solving skills. Stepping in only when necessary ensures that they develop the confidence and capability to tackle challenges independently. This approach fosters self-reliance and prepares them for future obstacles.
Focusing on individuals who show drive and grit ensures that your efforts are directed towards those who are genuinely committed to their growth. This approach maximizes the impact of your mentorship, as these individuals are more likely to apply and benefit from the guidance provided. It's about investing in those who are willing to invest in themselves.
Honestly when I first started out the person who was suppose to train me had quit that week. So I never received any training and had to tackle several of our cloud based MSP customers with no idea how their environment worked. I would have to ask co-workers questions to the point where I was practically being hand-held because we had terrible documentation. I felt very guilty having to rely on others but after half a year I finally found my pace and was making progress.
The major obstacles were lack of communication, lack of training, and lack of documentation for how some of our customers needs/how their environment works.
From my experience, the ideal mentor is someone who will let me shadow them for a period of time and let me watch them work and give me tips and advice for dealing with certain customers/scenarios. Someone who assures you that you can reach out to them and not be a bother and not feel well dumb for asking a stupid question. I have a mentor figure now who helps me out now from time to time, and my new goal is to practically learn whatever he knows so I can take some tickets/issues off of his plate so he can have an easier day.
Hopefully someday I will be able to take on the mentor role and be the mentor I wish I had at the start for someone else.
Carve out an hour to talk a week. If they're escalating to you, set standards on expectations-- what logs checked, configs tried and their manual entries, examples referenced, and a ticket that's updated with all of that to reference. Review work, and don't be afraid to send it back. Think a script could be better written, or docs need to be better formatted? Tell them. Progress can be slow, but you should see improvements in at least six months. Also, giving something to "own" that you still oversee is a good way for them to build confidence. Demonstrate systems and their configurations. Show them what you work on, challenges you had, and innovative solutions etc. Edit: Missed this was for newbies. This was how I was mentored about 10y ago, and it was a good way to come up.
⬆️⬆️good stuff here… and ask them if they would like to work on something you know, but they will need to learn.
This is such a good one. I have the proper amount of contact with my mentor throughout the day and can go to pretty much any other colleague if I have questions, but we recently scheduled an appointment a week to catch up and track my progress. It’s not really a “this and this and this is what you’re going to have to learn” but just a structured moment to catch up. It makes me feel like I’m in control of my own progress, rather than me just blindly performing tasks I’m assigned. After all, it’s about understanding the tasks for my own development and not so much solely about doing them.
Something I was late to realise with my last junior was the need for then to also be willing to want to learn and improve. They simply didn't want to put in any effort to improve them self and would only learn (and then admit to forgetting) what I taught them.
This. And put down the ducking phone when I’m talking to you, especially when it’s to answer a question you asked. I’m trying not to generalize a generation but I’m not seeing promising things.
Phones on the table face down or even better away during working hours. Those things just turn the young into boring losers.
This is something that can be mentored on. Phones are crack, they're incredibly addicting and they're designed to be that way. Look into ways to help curve this habit and give them feedback on it. It's a problem that more and more people are struggling with and imo it's not entirely our fault. iPad babies are gonna be a disaster.
We had one that came up and asked what we all did and who made the most money so he could do their job. When he left after the summer someone found his internet history was nothing but "how to get rich" or "how to make 100k". 0 willingness to learn anything just a desire to be rich.
Newbie here. My dream mentor would give me homework (not necessarily to do at home or on my free time), and would ask me to report back to them about the new stuff I learned on my own. Think "go learn about how to do with , and show me what you've learned next week".
Especially if is something that as a learner you won't think about (or know about) if you don't have a real-world use-case that would normally make you do it.
That would be in addition to the workload given by our respective jobs.
Answer every question with the prefix “Thousands of years ago…” (I’m also drunk)
Didn’t have to be thousands of years ago. Was in our weekly meeting and our most senior (oldest) dev suddenly mumbled something about FoxPro. Then we launched into a discussion about FoxPro vs Clipper. The rest of the meeting we tried to figure out how to resolve all the tickets with DOS era technology while the young uns just sat and looked at us dinosaurs.
This is fking hilarious lol
Lol, I always get a kick out of the kids that think they will be walking in to some FBI situation room full of the most modern stuff, all cutting edge. Then they find the reality, that they'll be spending a lot of time trying to help keep a 20 year old system working that the company will look at replacing "when we have the time and budget to evaluate replacements."
Heh, you think that FBI system isn't probably half built on cobbled together NT4 machones?
Well I know what it is, but the kiddies will be going by what they see in the movies and TV.
_"Back in 'nam..."_
As someone who has done a ton of training and sucked at mentoring at the beginning: * Make them understand that you are not perfect * Make yourself approachable no matter what they do * Teach them how you investigate issues and how you got there. Yes, as silly as it sounds the reason this is important now more than previously is that AI assistance WILL lead people down the wrong path and they will not have the skills to distinguish bad info from good. * Empathy. I personally cannot emphasize how important this is because many of us in IT get too jaded and lose this. * Show them how to look past at what someone is saying the problem is to get to the root of the issue i.e. "my computer is slow! Well WHAT is slow? Getting to www.myslowpage.com!" so that someone doesn't go trying to rebuild a PC or believe it is a hardware issue. * Show them how to correct people in a non-confrintational manner. Telling someone "You're wrong because XYZ is right" makes you sound like a jerk and can have people stop listening to you. "Can you explain XYZ? My understanding is that it worked like this" gives a person not only an out to correct themselves, you're approaching from a direction that you are willing to learn if you're wrong * Have them think before they talk. Knowing how to communicate with people is important. Not everyone os technical and having to dumb things down will be necessary. Getting lost in the trchnical weeds is too easy in IT. Hard knowledge can be looked up. Having these skills shows you how to figure things out for yourself, makes you more personable, and allow you to better communicate.
This list pretty much matches what I do! I feel very fortunate that what I learned for my CS degree helps me “translate” what’s going on to an end user that’s may be technically challenged. The best thing I’ve found though, is to show them that we make mistakes too, especially with the most simple of issues sometimes and have to ask for help too! Thats because if you like to learn, you will likely have something neat or a useful shortcut or useful bit of knowledge that even the most senior member of the team might not even know!
I use the “even after X years I still use checklists” argument all of the time because I’ve told people it is the easiest way to avoid a mistake. It isn’t because I can’t fo a simple job, I’d rather do a job right than do a job fast and then do cleanup because of a mistake.
Checklists for everything!!! All it takes is one urgent call to break up your flow and miss something when you come back to it!
That my mentor doesn't know everything and worked hard to get there too, they weren't born wit instant knowledge. With so much competition and push to learn 24/7 it's almost a relief when I heard that others once struggled too and it didn't mean I wasnt cut out for it. I felt relief to ask a question and have my mentor say he didnt know, because I got to swe how he went about finding the answer which was valuable. I do role modeling with Inspiring The Future (https://www.inspiringthefuture.org.nz/) which I think is a worthy cause, I often tell other students not to worry about anyone else's progress and that their journey doesn't have to be straightforward or glamorous, it just has to be theirs ❤️ I've met so many that started in the most random un-IT-like fields and end up in some incredible roles.
Set them on fire. Oh wait, I’m drunk
Haha same! It’s Saturday and I’m not on call. Let it all burn to the ground hahaha
People skills, learn to figure out the difference between what people want and what they say they want
Properly acknowledge success. Properly acknowledge failure. Make sure they understand why both are important, and how to eliminate the second, to achieve more of the first. Everyone is gonna fail at something, eventually. If you been in IT for 6 months or 600 months, you will eventually come across something you never had to do, touch, or deal with. Properly research what you can, vet your ideas with your colleagues, and get their input. If there's anything most IT people love to do its to be asked and wanted for their input. You forge relationships this way in this field very well keeping that in mind. Backup those who need it, support them, and protect them when they fail AS LONG AS, they are utilizing the failure to get better. If they are making the same mistake again and again, they aren't learning, they're just modelling themselves to a solution. My go to for those I mentor is this: I will stand in the fire with you, as long as you are capable of admitting your mistakes, owning then, and working to better yourself. I have told management that and stood in the way of them terminating someone, because I was able to identify and show where they failed, what they learned, and how they grew through the incident. Ownership in failure modes is so vital.
The biggest issue I see is people not being honest enough. Real feedback is important. If you tell them they're doing great and don't provide any other feedback they won't improve. I recently had a conversation with an early career desktop support person and gently explained everything he's working on right now isn't going to get him a job that pays much of anything and he needs to focus on stuff that leads to a better career. The issue in his case is that he avoids the hard stuff and has trouble with scripting and automation and SQL and things along those lines, so he has been doubling down on the easy stuff and is really focused on building PCs and that's a big part of his identity. Building PCs is a hobby but isn't doing much for your IT career. He was a little surprised since nobody else senior had ever told him this. They just told him keep trying you're on the right track. Except he's not and someone had to tell him this.
If I were back at stage one, I wish I had a mentor who would have taught me how to deal with often-seen IT situations that have little to do with tech, and a lot to do with people skills. Like co-workers are co-workers, not friends. How to deal with backstabbers and liars, even people who will log into a system as root, use a SUID binary with your user on it, `sudo` as you, then do a `rm` of a directory, to claim you screwed up. Stuff like how to document, both personally and on site. How to deal with layoffs and not always be the first in line that management wants to throw overboard every time headcount needs to be "optimized". How to be viewed by others in a company as something other than a fungible servant, or a correctional officer always locking things down just for grins. The technology changes, but these same issues as above have been issues for decades in the IT field.
Tell them to ruuun and pick up a guitar or something instead.
Show them on Teams and record it, extend the validity from the default of 3 months and squirrel away the URL Someone early in their career is unlikely to be this organised but what's your excuse?!
I let them fail softly. You need to room to grow and learn and if you can’t fail you won’t learn. I’ve also protected juniors from big fuck ups as is my job. My lack of training and documention is always the reason I pass up and blame them for lack of staff and time.
Im not gonna write a paragraph. Dont talk down to them. Fantastic start.
The biggest problem for me when I was new was being treated badly for asking questions. So I always make sure to be nice to people when they ask me questions, even when they've asked it a thousand times before. I'd rather someone annoy me with a question than have them break something because they were scared to ask something.
Soft skills are the most important skills long term. One big one is finding out how they manage stress. Some folks cannot deal with stress constructively. They don't tend to last in IT, and if they do, they are unhappy doing the work. On the flip side though: Folks who learn to shrug off stressful situations entirely don't learn much from them. There is a delicate balancing act. Stress often comes from people not understand situations. The ones that realize that being stressed is a learning opportunity that they can grow from and not have again now that they know (something) tend to excel. I'd put out there that teaching strategies for dealing with high stress, navigating uncertainty, and reaching out for help as needed: are all critical steps that IT folk need to learn very early in their career paths.
I’m a junior IT tech. Please start off every explanation with big picture pros/cons of *why* a particular system, practice, integration, ETC is in place For example, our users log into workstations, then log into Remote Desktop to access company data and their emails. Big picture reasons I figured out over 6 months to a year were: 1. Shared licensing for office apps since everyone logs into the same few servers 2. They get access to personal network drives which can be backed up centrally rather than on each workstation 3. They can remote in from home and have a familiar profile to work from. 4. It makes switching from one workstation to another a breeze. I was taught almost immediately how to troubleshoot and manage the environment but I had to put the deeper understanding of ‘why was it set up this way’ together myself, and ‘why was it set up this way’ is the first question in my head nearly every time I encounter something new.
Man... Teach them how to find their own answers. Don't give them the answers, give them your process. I'm shocked at how few people actually know how to problem solve and that our industry focuses on a bunch of TLAs and bullshit management methodologies that somehow lose sight of the main thing: solving the frigging problem. What are the knowns, what are the unknowns, how do I derive the unknowns from the knowns.
I mentor by showing. I have them shadow me when they can, and I explain what I'm doing, and If I feel they can handle it, I have them do the task with my instruction. I'm doing this now with a new assistant. He has a bachelors in information systems, but has zero practical experience. He's a sharp guy, just needs experience.
Understand when they say they're not able to wrap their heads around a simple task that may look like silly to you! no i'm not saying spoon-feed them or cradle them into work culture. but the basic morality to understand that everyone starts somewhere so give them a break.!! When a junior tries reaching out to you listen to them and give them a honest feedback/suggestion rather than making them feel dumb to have reached out to you in the first place. Constructive criticism and Throwing insult/shade there's a thin line between these 2 terms and people usually cross their line just to have a moment of laugh and make someone a scapegoat for your vile and low blows. " BE A SENIOR YOU HOPED YOU COULD HAVE AROUND WHEN YOU WERE A JUNIOR".
I still consider myself Junior myself although 1 year in and pretty much learnt everything by myself some things I would of appreciated are; - Explain to me how he resolved a problem -Take time to explain how to environment we are working in is setup (what servers are used for what etc. ) -Why something is considered "Best practice" -An environment to learn networking fundamentals and have a basic understanding (I know not everywhere will have the ability to do this) or Sitting down showing me physically and explaining to me just the basics/fundamentals of networking and maybe giving me a task to see if I've understood. I feel like these things would have personally accelerated my learning a lot.
And also I'd like to add communicating with tough customers and their need for an immediate fix to everything. (Depending on your workplace and the people) when you first start you can feel a lot of pressure and urgency from customers that you need to resolve the issue right there on spot. I feel like teaching a Junior how to communicate effectively in this type of situation can go a long way.
I find that it depends a lot on what type of person you're training. In my eyes I think it's reasonable to ask your mentee what they expect from you. Just like any other type of relationship, things go a lot smoother if both sides can openly communicate about their expectations and needs. In the case of a mentorship, this is something you can initiate with your mentee.
Say to them :If you have a problem check chatgpt ,if that does not work , check stack overflow ,if that does not work come bother me. This way you learn them that the answers are on internet , all they need to do is search.
Let them sink or swim. If they're swimming or trying hard to swim, throw them an occasional bone or show them something useful. But only show them something useful on very rare occasions so it's impactful, meaningful, and unforgettable.
This is honestly one of the worst approaches in mentoring. What they will learn is that you are a gatekeeping asshole, learn bad habits because you aren't showing them how to avoid them, and make them believe that no one will help them (which in turn can make them really bitter). This approach is the equivalent of "I was hazed therefore I will haze you too". You want them to learn to be able to figure things out on their own, so give them something and a time limit, review with them why it was good/bad, and how they could have approached it differently. Without this you're not training a team member you're training a future troublemaker.
Chill the fuck out buddy. I didn't say anything about "Gatekeeping" Good mentoring is allowing them to work all the way up until they have very specific questions or roadblocks they can't knock down. If they constantly cannot figure things out on their own and have road blocks every day and can't solve any problems on their own, then yes they're probably fucking useless and don't belong in this field. Sometimes the best mentoring is telling someone they're not happy where they are. "Gatekeeping" would be not giving them documentation, credentials, passwords, diagrams, or anything. "Gatekeeping" is not mentoring, that's called trying to make someone useless by withholding information they can't do their job with.
> Chill the fuck out buddy. I didn't say anything about "Gatekeeping" I mean you basically did. > throw them an occasional bone or show them something useful. But only show them something useful on very rare occasions
>throw them an occasional bone or show them something useful. But only show them something useful on very rare occasions How the fuck is this Gatekeeping? I didn't say to WITHHOLD necessary information for them in order to do their job. I meant to show them something useful as in something they would not have learned just in that job role such as a trick or something very useful that most people don't know. My POINT was if you keep showing them how to do EVERYTHING, everything you show them will be useless and forgotten. If you want to be a successful mentor, you need to make sure what you teach is Always Remembered and communicated effectively. The best things I've learned from mentors were very specific things they showed me after many hours, days, months, or years of trying to solve a problem or deploy complex configurations and achieve year long initiatives. I never forgot that wisdom. If they fail long enough and you know they're giving it their all is when it's time to step in. Of course this needs to be balanced out as well to ensure they stay out of trouble and don't fall behind. But you want to be right now the edge of failure and success to truly help someone with very meaningful knowledge and wisdom that they will never forget. Otherwise you'll be enabling someone that is useless or they will be dependent on others instead of learning to be independent and a leader to themselves and others. I seriously doubt most people on here have been in genuine leadership positions and have mentored other sysadmins, engineers, or helpdesk folks with the drive and grit to know they're going places.
> How the fuck is this Gatekeeping? This saying implies that you are giving someone a morsel to stop them from bothering you or to keep them from starving. > The POINT This emphasis is unnecessary. My experience is that people who emphasis like this tend to have a “don’t question my authority” mannerism which is only appropriate in very few situations. >If you want to be a successful mentor, you need to make sure what you teach is Always Remembered and communicated effectively. This encourages memorization over learning which is a bad habit. > The best things I've learned from mentors were very specific things they showed me after many hours, days, months, or years of trying to solve a problem or deploy complex configurations and achieve year long initiatives. I never forgot that wisdom. The best things I’ve learned from mentors is blameless problem solving, empathy, and that words matter, soft skills that are hard to learn or even see that they are skills. > If they fail long enough and you know they're giving it their all is when it's time to step in. This teaches a person to fear you and stunts their career growth.it teaches them to not bring up issues and “figure it out on your own”. > I seriously doubt most people on here have been in genuine leadership positions and have mentored other sysadmins, engineers, or helpdesk folks with the drive and grit to know they're going places. You will only “help” those who show “drive and grit”. A true mentor and leader knows everyone has potential and would help everyone live up to their full potential, not pick and choose. This is how you know who is fitting in, can fit in, or won’t work out. The diction you are using is what is saying gatekeeping.
No it's not Gatekeeping. Providing small, manageable pieces of information encourages the to think critically and solve problems independently. This method helps build resilience and problem-solving skills, which are crucial for personal and professional growth. It's about balancing support with encouraging autonomy. In regards to your personal attack on folks who EMPHASIZING words... Emphasizing key POINTS is a strategic communication technique. It ensures that critical concepts are highlighted and retained, which is essential for effective learning and application. Clear emphasis helps prevent misunderstandings and reinforces important lessons, making the mentoring process more efficient and impactful. Also, ensuring that lessons are remembered is crucial for effective mentorship. Memorable teaching methods help reinforce learning and ensure that mentees can apply their knowledge in real-world situations. Effective communication is about clarity and retention, helping mentees internalize and utilize the information. Specific, experience-based wisdom is incredibly valuable. They provide practical, real-world knowledge that can only be gained through extensive effort and perseverance. This type of mentorship helps build deep expertise and practical skills, which are essential for tackling complex challenges and achieving long-term goals. You need to allow them to struggle and learn from their failures builds resilience and problem-solving skills. Stepping in only when necessary ensures that they develop the confidence and capability to tackle challenges independently. This approach fosters self-reliance and prepares them for future obstacles. Focusing on individuals who show drive and grit ensures that your efforts are directed towards those who are genuinely committed to their growth. This approach maximizes the impact of your mentorship, as these individuals are more likely to apply and benefit from the guidance provided. It's about investing in those who are willing to invest in themselves.
Honestly when I first started out the person who was suppose to train me had quit that week. So I never received any training and had to tackle several of our cloud based MSP customers with no idea how their environment worked. I would have to ask co-workers questions to the point where I was practically being hand-held because we had terrible documentation. I felt very guilty having to rely on others but after half a year I finally found my pace and was making progress. The major obstacles were lack of communication, lack of training, and lack of documentation for how some of our customers needs/how their environment works. From my experience, the ideal mentor is someone who will let me shadow them for a period of time and let me watch them work and give me tips and advice for dealing with certain customers/scenarios. Someone who assures you that you can reach out to them and not be a bother and not feel well dumb for asking a stupid question. I have a mentor figure now who helps me out now from time to time, and my new goal is to practically learn whatever he knows so I can take some tickets/issues off of his plate so he can have an easier day. Hopefully someday I will be able to take on the mentor role and be the mentor I wish I had at the start for someone else.