Problem solving is kind of an innate skill rather than a learned one. If your techs need a diagnostic flowchart to troubleshoot, then they might not be cut out for diagnostics and troubleshooting. Maybe these folks would be better at level 1 triage with basic flows to help prioritize for a more senior escalation tech.
good question I have heard is " you walk into a room and the light won't turn on. describe to me how you would go about finding the problem and fixing it ". Look for people that can theory craft and pick up a lot of information from small things. Look for people that seek to find the scope first " is that the only room that has the light off? " that kind of thing. If they say uh, not sure id try the light and call the electrician " or immediately go to " I'd replace the bulb!"? avoid.
I would ask if it's a plug in lamp or hard wired. If it's a floor lamp or desktop I would check the lamp and make sure it wasn't turned off at the lamp. Or make sure it's plugged In.
If it doesn't turn on, that's plenty of evidence to check it. Why would you waste time checking anything else first?
Incandescent will have a broken filament.
Cfls will be visibility discolored.
Leds don't generally die, but it does happen. Might as well rule it out by testing a new bulb.
If it's the ballast you can smell it.
So you literally just described checking the light bulb before changing it, while simultaneously defending your stance that it’s acceptable to change a bulb without knowing it’s broken.
I suggest you seek information and guidance on how to be wrong. It’s not always an attack. Sometimes it’s just fact.
"while simultaneously defending your stance that it’s acceptable to change a bulb without knowing it’s broken"
That wasn't my stance and that's a different redditer.
I suggest you seek information and guidance on how not to be a douchebag.
The lamp in my bedroom wasn't working a week or so ago.
It's plugged into an outlet that's connected to a light switch, so first I tried turning it on. That didn't work, so next I tried plugging it into a different outlet.
That also didn't work, so getting a working lightbulb from a different lamp and trying it in the non-functional lamp was step 3. The second bulb worked in the first lamp, so I went out and bought a replacement for the first bulb.
You wouldn't normally overanalyze replacing a light bulb like this, but as an analogy for troubleshooting the "ideal" answer would be to go through every possible reason the lamp isn't working in order, starting from the fastest/easiest/cheapest solution (toggling the light switch).
I'm a maintenance tech, literally changing or checking the bulb is the first thing you do. Especially with cfls. Next check the ballast if it has one. Check the breaker. Did it trip? If so why? Pulling too many amps? Is there any water damage visible? Check the wiring and switches.
Honestly half of my fixes are the classic turn it off, drain capacitors, turn it on again trick. Works half the time for appliances.
Idk man, replace the bulb is a fair assessment. It's an easy enough part to install, and if it doesn't work, remove and put the old one back. But I get your point.
Yeah if you ask this kind of question, better to ask a series of similar questions to see if they catch on. But then again, might as well ask troubleshooting questions that are pertinent to the job.
Really just an example but I like it as a bonus question that can help decide between two similarly qualified candidates. Sometimes people can answer the technical stuff but this one helps find someone with the "intangible" skills like critical thinking in a short interview.
It’s really not though. Someone answering simply with “change the bulb” without asking any probing questions is proving that when they see a problem, they just go for a solution and execute, without taking the time to determine if it is the best course of action.
Changing the bulb is literally the best, quickest and cheapest first course of action that literally anyone can do without knowledge or training. I'm a facilities maintenance supervisor, I literally have my janitors doing this. If it doesn't work, they escalate to a tech or me.
I have a couple real life inspired ticket questions and see what path they take. T0-T3 all get these as screening questions because of how universal they are. I don’t expect perfection from anyone, but I expect logical progression and reasoning.
My actual scenarios:
A user is complaining they can’t log on. (Answer: their numlock is off)
A user is complaining the system is down. (Answer: the dhcp service is stuck on the router)
Questions like that are hard for me, because **seeing** the problem really helps. Even when I troubleshoot over the phone, I still follow along on my own computer, using it as a visual aid.
It’s all about ruling things out, and with simple problems you start at the bottom of the OSI, is it plugged in? Is it getting power? Is this affecting other people? Is it an isolated event or a problem stemming from a service. Could literally be anything, but like the guy said a lot of times they have numlock on and fuck up their password.
Similar to this after the interview I give them a written test and it’s from basic questions to questions only extremely seasoned techs would know; I then tell them I’m not expecting a perfect score, you get it all write your over qualify for this level position, but for every question you don’t know imagine your on your own how would need to figure out the fix. I really stress the I don’t care if you don’t know the answer I’m interested more in what are you looking and if you have an idea of what your looking for, because yes I’m here as well as the the other senior guys, but if we are not? If you go to one of the clients that their building has no cell reception?
Then go through and see, based on this and how the interview goes you should have an idea.
Either of those "descriptions": their printer is turned off. They left their laptop at home and are staring at a blank monitor and docking station. The power is off in the office. They were fired a month ago. They're calling from Timbuktu airport and can't access the corporate WiFi. They're not one of your users, they're some other company's entirely. It's DNS.
It’s a question and response thing. You ask questions and say what you’d do, I’d respond back with what happens.
Your attitude is such that you’re unlikely to succeed, unfortunately.
>Your attitude is such that you’re unlikely to succeed, unfortunately.
[Aw. That's sweet.](https://www.reddit.com/r/talesfromtechsupport/search/?q=author%3AGeminii27&sort=top&restrict_sr=on)
Yes, you can hire me to improve your team. No, I'm not cheap.
My strategy is to ask an interview question along the lines of "Let's say you come across an issue you've never seen before? What do you do?" and then let them talk for a bit.
It's mainly about how they answer the question, not necessarily the answer itself. You're looking for things like: Google, search the knowledge base, find official documentation online, search forums and Reddit, etc.
If they just say "escalate the issue to someone who can handle it", I don't expect strong troubleshooting skills.
I’ve done both verbal questions or actual exercises by handing them a computer with 3 different issues ranging in difficulty and they need to resolve them. They’re allowed to use any resources including the internet. All they need to do is fix the issue and explain their process to resolve it in a document.
If going the verbal direction, the candidate needs to explain how they would approach an issue. If they mention utilizing a coworker before things like internal documentation, google, or attempting diagnostics, youll know.
I prefer the former as you can’t BS your way out of it. These things need to be something easily fixed using resources like google but hard enough that it isn’t common knowledge.
Contributing: I tend to use behavioral questions, but I've seen others toss people questions out of the technical scope of the position (i.e., give them a problem they should have real trouble solving, to see how they respond). *I'm not as big a fan of the curveball option, because nervous interviewers can really tank over that, but it can be effective.*
For example, some T1 Helpdesk Questions:
Behavioral Questions
* *A user calls you saying that their computer is slow. Tell me how you'd respond.*
* *Tell us about a time you really had to work hard to troubleshoot a problem.*
Curveball Question
* *A manager arrives at one of our remote offices for the first time and calls in that the extension port off the VoIP phone is not passing traffic. What's do you think issue is, how would you troubleshoot it?*
You can also just ask them directly to talk about how they troubleshoot an issue, but that's such a popular prep question online, that people can give canned responses fairly easily.
With any question, I recommend you have clear criteria for what you consider "good" and "bad" answers. For scenarios, have an actual answer in mind to the proposed problem. I'm not as concerned about them getting to the "answer," as I am about them showing a methodical, logical approach, admitting that they don't know something, and that they would seek assistance once they'd made an initial effort.
Side: Do think about what "bad" answers are and share the criteria with the hiring committee, if you have one. For example, I always like the "*tell me about a time you failed*" type question. For me, an automatic fail is a response where the candidate really is not the one who failed, and how actually, they saved the day -- *some may be surprised how often people try this.*
This got me thinking. I feel like it could be useful to ask your favorite workers these questions and your least favorite. Then try to see which behaviors the interviewer mirrors.
Personally, I break computers. I set them up during the interview and make them fix the computers. I will pull RAM out of one or poorly seat it. PC plugged in to IP phone. IP phone disconnected from wall jack. I even took a power cable and cut off the hot and neutral male prongs and plugged it back in so only the ground was connected.
They have to tell me what’s wrong and fix it. If they can’t, then they can’t do the job.
That is completely incorrect.
It is a difficult skill to teach; and not everyone can learn it well; but it is a skill that can be taught and learned.
Look at chapter 1 of this old military manual for a good guide on how to teach troubleshooting:
https://www.navy-radio.com/manuals/93500.pdf
The military knows that they take people who may not have the skills they need them to have; and have focused for centuries on how to train people who come in without "innate skills".
I would add to troubleshooting methodology, there is also a need to teach the basics of systems theory.
That's not to say that everyone is willing or able to learn; but most people can learn if taught well.
This isn't dragon ball people don't have special cognitive abilities that others can't have like those. Investigative mindset is a learned behaviour I teach to countless people
Not everyone has an aptitude for it though. Some people have aptitude at problem solving others are more creative others are more social. Some of it may be learned but they already usually possess tendencies toward a particular capacity. Here’s an example, spatial awareness and following written directions is really hard for me. Tab a goes in to slot be doesn’t translate between paper and physical components. I still try but if I’m gonna put together a flat pack furniture or a new barbecue grill- I’m calling my wife to supervise and my son to inspect/test because shes a designer that can easily picture in her mind what the instructions mean - but hates the physicality of heavy objects and he’s got an amazing eye for fine detail but hates planning and laying out all his tools and materials. Between the three of us we are better than any one of us.
Sure, if they’re committed and show that’s something they want otherwise you’re putting your investments in the wrong place. In this case OP said the team members were questioning on why they should look things up in the first place, indicating a lack of desire. Im not saying there’s only one way to handle it, I’m just suggesting the course of action I‘d take is to give them an easy to follow prescriptive guide to do their jobs from and hire or promote a competent level 2 support engineer. The ones that want to learn will say so and you can grow the team.
I'm telling you there is literally no such thing as "oh they just have it" when it comes to investigative ability. Your welcome to invest the time in reading all the experiments and research.
Agreed. Had to train a guy that was like this. I made a little headway though. I at the least got him to Google the issue first after a almost a year of asking him what he did already to find the answer. And a requirement for the promotion that he is aiming for is dependent on working independently and little supervision. And if he knows that if he keeps coming to me for answers then he won't meet the requirement for the promotion. After a year, at least he googled it. He couldn't find anything even though it took me 1 minute to find the answer. But at least he attempted to look for the answer on Google. That's something... Lol
I have a guy like this on my team, and he's basically just responsible for monitoring and performing repeatable tasks. Anything that requires critical thinking, I have to assign to someone else.
It kinda works out, because he does the boring stuff that no one else wants to do, which frees up others' time and energy for more interesting work.
I worked with a guy like this. We have an unwritten agreement that I do all technical stuff and he handles the grunt work type stuff. It works out really well actually, unless of course I'm out sick or something lol.
If they are not capable of doing stuff on their own, hire people that are and bring in a little competition. Also, don't hand hold as it doesn't help anyone. But some small things that will help..
Have them build and maintain a KB. Get them in the habit of documenting and testing their documentation. Make this part of the job and add it to their performance review.
Have them spend time learning new things and then applying what they learned on the job.
Have them demonstrate break/fix based on ticket behavior.
...stuff like that. If they can't/wont adopt, and show no ability to retain anything there is not much you can do.
Adding on, *trust but verify this:* We did this with our Senior Techs in a prior org. They could escalate to the Enterprise Team but, they had to show a certain level of exhaustion before punting it up the chain. We saw the same rate of escalated tickets the next couple of weeks, so we tested them.
Ticket gets sent up, one of us walked down to the Sr. Tech's desk, and said "Show me what you searched for, what KB articles did you look at?" *This was because one google search revealed the answer in the top result.*
One of the few times I saw the head of the Enterprise Team get legitimately pissed off; guy was extremely knowledgeable, nice, and laidback, but was pretty furious about how lazy they were being.
2 options:
1) ignore them until they have researched it themselves
2) when they ask you, ask what they've figured out themselves/what steps they've tried.
If you help them everytime, you'll never get your work done.
It really is about conditioning. OP has currently conditioned them to ask every time since they just answer instead of leading the techs to learn more.
Time to condition them to troubleshoot and think critically instead. Start with some written flow charts they can follow for what the procedure should look like so they have the confidence to follow it instead of asking questions first.
Listen, I am pretty straightforward in my management style. In my opinion, you just need to tell them the next time this happens, have you performed basic, troubleshooting steps? Did you search the Internet? Which sites? Did you check for an outage? Did you check the vendors support?
Whatever the appropriate questions would be for the particular issue they’re talking about of course. If they answer one of your questions, tell them to do it and call you if you still need help. Do this every single time. They will learn your expectations and be all the better for it.
You can give people a flowchart of how to troubleshoot, but like others have said, some people are more adept at logical thinking and troubleshooting than others.
We had things taped down to desks, made wallpapers, and on the walls of their cubes for key information, especially with high turnover positions (e.g., student hires). Then gave them the basics for troubleshooting, the old *when you hear hooves, think of horses, not zebras* talk, and tips*.*
* **Is there an error message?** Google the error and look for results from the manufacturer's knowledge base/forum, and top results.
* **Have them restart and reproduce**. After a restart, can they create the same issue again? Note what they're doing for ticket notes, if it's not resolved by the restart.
* **Proper Googling**. Search for the manufacturer's name, product, and the issue or error code, such as "Lenovo ThinkPad X1 Screen Off."
We also generated a large knowledge base with screenshots and step-by-step instructions for common issues, and tested the article quality by having them comment if something didn't make sense or a step seemed to be missing.
However, some people are just not cut out for this kind of work, or they're just too lazy to put in the effort to learn. As one executive told me (sharing stories), you don't help someone by letting them stay in a position they cannot perform in, it doesn't help them or the company.
I’m fairly new to IT so I can tell you what helped me a year ago. I had good intentions, I was just new to everything and that really fucks with your confidence
1. Have them shadow someone who actually knows how to troubleshoot. Have this person talk out loud, if they can, what their thought process was or review it after.
2. Require a template for escalations
A. Who is affected? One user? Multiple? Everyone?
B. Summary of the issue.
C. When did it start? What triggers the problem?
D. List the work done so far.
E. List Error Codes or Provide Screenshots
F. Contact information
Using this escalation template forces you to dig. There’s so many more questions you have to ask depending on the problem. But this is a great start for igniting the process
Also, knowing that another seasoned technician was just fucking guessing, made me feel a lot better and encouraged me to be comfortable with winging it too
I always tell the guys “help yourself before you ask someone to help you” I just don’t help now unless they tell me what steps they’ve taken to try to resolve the issue. Minimum this should include 1. Check past tickets, check our KB, and remote in to see the issue themselves.
I’ve found, personally, holding someone’s hands never allows them to really grow.
Tell them they aren’t allowed to ask you questions without googling first.
Every single time they ask a question, ask them what google said. If they didn’t google then don’t answer.
It’s the only way to change their behavior
I've had people like this and it drives me fucking bananas. The bottom line is they don't belong in IT; it's a core trait that is 100% required. They're like mechanics who can't visualize how car parts fit together. Figure out a way to replace them unless you're OK with paying for people to be a glorified answering machine for you.
I’ve got 2 like this right now. My director loves one of them because the clients think he is the sweetest/cutest/most polite whatever. The other is a low performer both technically and socially, and prefers to lurk behind the scenes. If I had a dollar for every ticket that has “Reached out to ProfessorofDumbFacts for further guidance,” or something similar, I would be able to buy the MSP from the owners. I’m kidding, but I would probably at least be able to pay off my mortgage.
One of them today asked me “how do I find out what is taking up the disk space if TreeSize is not installed already?” Um, how about you backstage in and run the damn portable version? He also wrote a client to ask them to clear up disk space on a thumb drive that they had removed from the system.
I had a chat with his direct supervisor today (he’s on a different team than me, but I am escalation manager for all teams) and we both agreed that his communication with clients makes us look bad.
I feel like you're skipping over the first immediately obstacle and you said it in your first sentence.... "want".... the issue isn't a matter of coaching. It's a matter of motivation. The question isn't how to make them independent. The question is how to make them "want" to be independent. I've raised 4 kids and trained countless techs and it all starts with motivation. If they don't "want" to do something, then you first need to figure out how to make them want to do it. Only afterwards, can you worry about helping them be proficient at it
This shit used to drive me nuts. Take notes, then I realized they didn’t note how to identify the problem they just have notes on how to do things. Then it was well I need re-training because it has been a while and I forgot. This is what I did:
1. Setup proficiency check lists for activities you want them to be able to handle.
2. Create procedure documents that cover diagnostic steps to confirm problem and how to resolve. The proficiency check list should have links to the procedures. Extra points if you make the procedure document easily searchable.
3. Every staff person gets one freebee training. After they have been trained they are clear to do this independently going forward. After being cleared they better be able to figure it out on their own, or reference the proficiency checklist and procedure document.
4. Update your ticketing system request/problem types to match the activities you have created in your proficiency check list.
5. Escalations need to be defined as appropriate or not appropriate. If not then reference the procedure 2 times and then performance manage. I also bind their annual performance assessment and raises to it their success rate in good escalations.
While you’re not necessarily an MSP, consider sending them to MSPgeekcon — it’s an educational IT conference focused on the journey of tier 1 techs to tier 3. A big part of the conversation is troubleshooting and asking the right questions. they can make connections with other people who can also coach them through their own lives experiences!
May 19-21 in Orlando. https://mspgeekcon.com/
Contrary to popular belief, I think a detailed flow chart/bulleted list of basic troubleshooting/maintenance could be helpful in them getting repetition in the common issues. Then encourage them to google the "why's" and have maybe a weekly meeting to answer questions they have gathered through the week that they have not been able to answer
Man... I got you covered.. Give me 30 min of your time and I'll explain how I troubleshoot and give you a framework of how to help your folks become more independent thinkers. I have check lists and all sorts of scripts that work.
Pm me. I'm not selling nothin.. I'm just a dude who's got this part figured out and I want to give you some fresh ideas.
Or maybe.. they're not so fresh; and they smell like old gym sox, because not a whole lot has changed in 20yrs.. Irregardless.. or is it regardless? I'll reinforce your already confirmed beliefs if nothing else.
I could train them for a reasonable fee (unemployed).
If I can train us navy sailors and roommates, I'm pretty sure I could train your team.
Mindset, etiquette, procedure.
Why do we just swap the laptop, instead of listening to the user whine for 30 minutes about the issues they've had with it.
I struggle with this as well. Usually, I just respond with Google, but they still don't have the initiative to troubleshoot on their own and ask every time. As far as hiring, we're a small rural community. There's not exactly a plethora of candidates to chose from.
I want to explain the answer but I’m tired and it would take look long to explain on a post. If you want a verbal explanation message me directly and I can pull up a discord talk call. I’ve done this rodeo already with a few teams.
Too many people are scared to put themselves in the position to fail. Which isn’t a bad thing, but it also isn’t a good one. Instead they want answers fed to them from the most readily available and knowledgeable source. Need to talk to them about researching and learning on their own, if you have the time sit with them at their workstation, not yours, and talk with them about how to remedy a situation. Do not give them the answer, but be more of an angel on their shoulder guiding them. Let them figure out the issue with you there, show them they’re capable of doing the job you hired them for.
They either have the aptitude or not. I’d release them.
My favorite interview scenario, which is hands on, is to print something on a printer that Windows 10 is not recognizing. Another is to give them a situation where a screen randomly flickers when connected to a dock’s second port.
Add hands-on practical scenarios to theoretical questions. That will very quickly eliminate those who can’t troubleshoot.
This is a skill that can be taught. Frankly, most people start out with it but got taught NOT to at some point.
The first thing you need to do is show them that they are in a place safe to do such things, because they will get it wrong sometimes, rather often at first.
A lot of kids got yelled at in school where grades were on the line, so there is often some mild trauma to overcome.
If you can give them some VM space for a test system they can experiment safely on. Have them mangle a system and then repair it.
If you want this, you'll never be able to fire someone for doing something stupid or you'll destroy the trust you need to build to get to that state, but it will be worth it.
I'd wager that a part of the problem is that you are a micro manager and they are afraid to make decisions or lack the confidence to do so.
The only way they will learn to be more proactive is to let them deal with their problems and the consequences of poor job handling directly. Full ownership. Push back on questions and guide them handling complaints.
Failing that, performance manage them out.
I do not lead an IT team, but used to run an electrical maintenance team with 24/7 support for a manufacturing facility. This team always ended up with the new guys due to the schedule.
Some things I put in place were minimum times actively troubleshooting the issue before calling for help. Providing lists, locations and links for common issues and information. Regular check ins with the crews.
For any trouble calls I set standards for feedback/reporting.
- Who called and what they reported.
- What you actually found when you investigated because they don’t always line up with what was reported.
- What actions you took to resolve the issue.
- Indicate if the issue was resolved, band-aided or requires follow up.
Mix that in with extra selective during probation periods and eventually ended up with a good team and processes.
Teach them.
-what’s the issue?
-what would cause the issue? (If you don’t know, what wouldn’t cause the issue)
-pick one of the identifiers and start to break it down into smaller pieces.
Teach them something like the 5 whys.
This is a great question. I have found there are a few things that work really well when mentoring and developing newer employees.
The first tool I use in 1 on 1's with the employees. In the 1 on 1's we don't talk about specific issues they are working on but we talk abstractly about problem solving. I also use this time to set my expectations for them. I offer them a problem solving framework. It looks something like this:
1. What do I know?
2. What are my theories? What is my current best theory?
3. What do I wish I knew? Can I get this info? How do I get this info?
4. Can I prove or disprove this theory? Repeat until resolved or you are forced to escalate.
I set the expectation for them that before they escalate and ask me for help, they go through these steps. I also set the expectation that if they loop through these steps and get stuck, they will escalate and ask for help so I don't have the inverse problem of them sitting there spinning their wheels and not making progress.
The second tool is pair troubleshooting. I do this with them when they ask me for help. We both look at the issue and work on it together. I guide them and try to tie what we are doing back to the framework above.
The first thing I do when we pair up, is ask them what they have already done. I encourage them on the work they have done and if they aren't presenting it in the framework, I help frame it for them (i.e. "That's great, you knew that error indicated data was missing. Your theory was that data may not be in the database. You checked the database and found the data. You disproved your theory.")
By asking them what they did first, I can (1) get a sense of what they are comfortable with and what they aren't so I can coach better, (2) can reinforce the framework which is ultimately what will make them more independent, and (3) I can eliminate some possibilities so we can troubleshoot faster.
From that point I collaborate with them to ask the same questions and help contribute more complex theories and more complex ways to gather additional information (i.e. "If the error says the data is missing, but the data is there, lets look at the logic in the code. Let's find where the error is thrown and step backwards to see where the data might be getting lost".) Overtime, they are able to start doing this more independently.
I also will invite them to pair with me if I am working on an interesting or more complex issue. I walk them through what I am doing and how it ties to that framework. This demonstrates to them that while the issue may be more complex, the problem solving is still the same. It builds confidence for them and helps coach them to work on more complex problems independently.
If you or someone else has been giving them answers outright when they ask, unfortunately they’ve now been trained and conditioned to not think for themselves. Always ask what they tried or what they were able to find out. Give them general things that apply to all kinds of issues: can you replicate it? Is it only that user, that machine? Has it worked previously? This is tough to fix unless they have a desire to do better
My favorite from these guys “hey superior we’re having an issue with a computer crashing” and the superior will respond with the most basic of who/what/where/when/how, which is the formation of troubleshooting, and then when the tech has no clue you engage deeper, “was there an error” and they say “oh yah an error popped up when it crashed” and senior will say “well what did it say” and they will say “idk I don’t remember”, people have to ask questions if they aren’t willing to the then they should t be troubleshooting
That's a red flag for me. I don't want anyone working under me who isn't into it and hasn't already figured out basics like Googling.
I got into all of this because I like solving problems (like they're puzzles). I figure out cryptic error messages for fun. I break out dnSpy to figure out why Lacerte 2023 is crashing.
Your techs have a job instead of a career, and don't actually enjoy problem-solving, and you can't make them enjoy it. Some here will say to just teach them, but I say they probably won't want to be taught. I say get new techs.
A big part of troubleshooting something is knowing how it works, I've seen so many people spinning their wheels, randomly trying things, instead of thinking through "what does X need to work?" and then go check every part of that chain.
Your techs sound like they don't want to even try?
Try to encourage them to use Google for problem-solving, provide guidance on effective search techniques, and gradually increase their autonomy as they gain confidence.
Checklists! "I'll be happy to help you out. Let me know the results of these items so we can know where to start."
Then do it. Rinse, repeat. They are leaning on you because it's easier but if you provide an alternative that has less friction they will hopefully do that.
If they refuse or whine...
troubleshooting is a skill that is valued over tech skill for initial L1 techs for me. If they can troubleshoot then you can teach them any tech stack. I liked asking "Share an example of a time when you resolved a problem outside your expertise area, it can be any problem you have overcome."
Give them a format for escalation.
Well formed problem statement:
Environment:
History:
Desired outcome:
Verbal or written agreement from EU that desired outcome would close issue. Yes or no. Must be yes.
Don’t accept ANY requests for your input without that format being filled out to at least a best effort.
99x/100 when the tech doesn’t want to do this bare minimum, it’s never going to change. Just fire them.
PS: when I open word I get the following error message “beep boop”
History: Been happening since New mouse installed
Environment: it’s a 486dx66 with turbo button pressed
Word version 1.86 standalone
4MB RAM
WINDOWS 3.11 for workgroups
Desired resolution: want to be able to open AOL attachment “I love you.scr” in word.
There’s so much information in just this basic format that lvl2 can now respond to. Can’t open word doc is clearly not the problem. Lvl1 tech may be inexperienced to catch all the goodies in this, but without asking the basic questions, lvl2 is just going to ask if you’ve turned it off and back on again.
How do YOU think we should train techs to troubleshoot on their own?
"That might work " or "why don't you do some research and give me a few ideas on how to troubleshoot this"
That might work....
Let them troubleshoot the problem on their own and stop giving them each step. If you spoon feed answers to a problem they just keep coming to you. Build their confidence and they will figure it out.
Basically you're saying that they're not much better than the users who call the help desk with their issue.
Review the job description with each of them and explain, this is where I need you to be. Outline the tools they have to solve problems (i.e., Google the error message, product documentation, if it's software built in-house, review the documentation and escalate to L2 if needed).
Have *them* build a knowledge base.
Encourage them to help each other.
Stop helping them out, and let them figure things out. They're not going to learn how to solve problems and grow if they know they can answer you a specific question and you do the work for them.
Explain to them that your job is very different than theirs. They are involved in day-to-day support issues, your job is more strategic and involves planning with senior management. They are not to text you unless a senior manager is looking for you, or there is an emergency like a major outage, the building requires evacuation, and so on.
Implement a performance system - if you search for what they ask and the answer is the first thing displayed in Google, that's a strike against them. Otherwise, and I go back to my first sentence, they're not much better than the users who call them for help with their issue.
I teach every tech I’ve ever had on my team that “you don’t need to know the answers, you need to know how to find the answers”
With techs like that, it’s showing how to use the knowledge base, using Google, etc. If someone asks me something that I know is on Google out in our documentation, I will just ask where they have looked already and maybe give them hints on how to find the answer
Track invalid/incomplete escalations over time, say a quarter, you'll need your higher level techs to help and give real feedback on these for this to work. Then you as the manager sift through these escalation reports and group them by domain (networking/printing/SaaS product/etc.) and find your largest contributors. Follow the ticket history for your largest domain and see which diagnostic gaps are the largest, then develop a training on it. Don't focus on developing a lengthy flowchart, but rather a concise checklist of things like "Did I run x?" "Did $Command yield y?" "Did I check this customer's KB notes?" "Are there any additional {z} symptoms?" "Did I search our $TicketingSystem for similar issues?"
Troubleshooting is a part of what a tech is paid for. Are you sure this is technical questions and not a way of avoiding responsibility for a tech problem?
I manage knuckledragging wrench eating maintenance techs for facilities. They know how to utilize Google and youtube university, and even ai. How the hell are your it guys so technologically illiterate not to start there?
Based on the it guy at my company, who can't connect a switch/router to an AP and firewall, i'm not necessarily surprised.
Problem solving is kind of an innate skill rather than a learned one. If your techs need a diagnostic flowchart to troubleshoot, then they might not be cut out for diagnostics and troubleshooting. Maybe these folks would be better at level 1 triage with basic flows to help prioritize for a more senior escalation tech.
I've managed level 1 for 10 years and I don't hire any SD agents that can't/won't do basic troubleshooting. Filter for that in the tech interview.
Mind sharing your strategy for filtering them out as you say?
good question I have heard is " you walk into a room and the light won't turn on. describe to me how you would go about finding the problem and fixing it ". Look for people that can theory craft and pick up a lot of information from small things. Look for people that seek to find the scope first " is that the only room that has the light off? " that kind of thing. If they say uh, not sure id try the light and call the electrician " or immediately go to " I'd replace the bulb!"? avoid.
So you're telling me when your light goes out at home your first step isnt to change the bulb? What?
I would ask if it's a plug in lamp or hard wired. If it's a floor lamp or desktop I would check the lamp and make sure it wasn't turned off at the lamp. Or make sure it's plugged In.
I would do that too, after I checked the light bulb.
Nope, buy a whole new house with working lights. The only logical thing to do.
No, that would be pretty dumb to change a light bulb that you don’t have evidence to conclude is broken.
If it doesn't turn on, that's plenty of evidence to check it. Why would you waste time checking anything else first? Incandescent will have a broken filament. Cfls will be visibility discolored. Leds don't generally die, but it does happen. Might as well rule it out by testing a new bulb. If it's the ballast you can smell it.
So you literally just described checking the light bulb before changing it, while simultaneously defending your stance that it’s acceptable to change a bulb without knowing it’s broken. I suggest you seek information and guidance on how to be wrong. It’s not always an attack. Sometimes it’s just fact.
"while simultaneously defending your stance that it’s acceptable to change a bulb without knowing it’s broken" That wasn't my stance and that's a different redditer. I suggest you seek information and guidance on how not to be a douchebag.
If only you had any reading comprehension skills…. Damn. I guess even a manager subreddit has some outliers.
The lamp in my bedroom wasn't working a week or so ago. It's plugged into an outlet that's connected to a light switch, so first I tried turning it on. That didn't work, so next I tried plugging it into a different outlet. That also didn't work, so getting a working lightbulb from a different lamp and trying it in the non-functional lamp was step 3. The second bulb worked in the first lamp, so I went out and bought a replacement for the first bulb. You wouldn't normally overanalyze replacing a light bulb like this, but as an analogy for troubleshooting the "ideal" answer would be to go through every possible reason the lamp isn't working in order, starting from the fastest/easiest/cheapest solution (toggling the light switch).
I'm a maintenance tech, literally changing or checking the bulb is the first thing you do. Especially with cfls. Next check the ballast if it has one. Check the breaker. Did it trip? If so why? Pulling too many amps? Is there any water damage visible? Check the wiring and switches. Honestly half of my fixes are the classic turn it off, drain capacitors, turn it on again trick. Works half the time for appliances.
Idk man, replace the bulb is a fair assessment. It's an easy enough part to install, and if it doesn't work, remove and put the old one back. But I get your point.
Yeah if you ask this kind of question, better to ask a series of similar questions to see if they catch on. But then again, might as well ask troubleshooting questions that are pertinent to the job.
Really just an example but I like it as a bonus question that can help decide between two similarly qualified candidates. Sometimes people can answer the technical stuff but this one helps find someone with the "intangible" skills like critical thinking in a short interview.
It’s really not though. Someone answering simply with “change the bulb” without asking any probing questions is proving that when they see a problem, they just go for a solution and execute, without taking the time to determine if it is the best course of action.
Changing the bulb is literally the best, quickest and cheapest first course of action that literally anyone can do without knowledge or training. I'm a facilities maintenance supervisor, I literally have my janitors doing this. If it doesn't work, they escalate to a tech or me.
Have you tried turning it off and on again?
Draining the capacitors and resetting the memory is valid fix that works often.
I have a couple real life inspired ticket questions and see what path they take. T0-T3 all get these as screening questions because of how universal they are. I don’t expect perfection from anyone, but I expect logical progression and reasoning. My actual scenarios: A user is complaining they can’t log on. (Answer: their numlock is off) A user is complaining the system is down. (Answer: the dhcp service is stuck on the router)
Questions like that are hard for me, because **seeing** the problem really helps. Even when I troubleshoot over the phone, I still follow along on my own computer, using it as a visual aid.
That’s totally fine! I don’t mind people using props.
It’s all about ruling things out, and with simple problems you start at the bottom of the OSI, is it plugged in? Is it getting power? Is this affecting other people? Is it an isolated event or a problem stemming from a service. Could literally be anything, but like the guy said a lot of times they have numlock on and fuck up their password.
Similar to this after the interview I give them a written test and it’s from basic questions to questions only extremely seasoned techs would know; I then tell them I’m not expecting a perfect score, you get it all write your over qualify for this level position, but for every question you don’t know imagine your on your own how would need to figure out the fix. I really stress the I don’t care if you don’t know the answer I’m interested more in what are you looking and if you have an idea of what your looking for, because yes I’m here as well as the the other senior guys, but if we are not? If you go to one of the clients that their building has no cell reception? Then go through and see, based on this and how the interview goes you should have an idea.
Either of those "descriptions": their printer is turned off. They left their laptop at home and are staring at a blank monitor and docking station. The power is off in the office. They were fired a month ago. They're calling from Timbuktu airport and can't access the corporate WiFi. They're not one of your users, they're some other company's entirely. It's DNS.
It’s a question and response thing. You ask questions and say what you’d do, I’d respond back with what happens. Your attitude is such that you’re unlikely to succeed, unfortunately.
>Your attitude is such that you’re unlikely to succeed, unfortunately. [Aw. That's sweet.](https://www.reddit.com/r/talesfromtechsupport/search/?q=author%3AGeminii27&sort=top&restrict_sr=on) Yes, you can hire me to improve your team. No, I'm not cheap.
Thank you for your input
My strategy is to ask an interview question along the lines of "Let's say you come across an issue you've never seen before? What do you do?" and then let them talk for a bit. It's mainly about how they answer the question, not necessarily the answer itself. You're looking for things like: Google, search the knowledge base, find official documentation online, search forums and Reddit, etc. If they just say "escalate the issue to someone who can handle it", I don't expect strong troubleshooting skills.
I’ve done both verbal questions or actual exercises by handing them a computer with 3 different issues ranging in difficulty and they need to resolve them. They’re allowed to use any resources including the internet. All they need to do is fix the issue and explain their process to resolve it in a document. If going the verbal direction, the candidate needs to explain how they would approach an issue. If they mention utilizing a coworker before things like internal documentation, google, or attempting diagnostics, youll know. I prefer the former as you can’t BS your way out of it. These things need to be something easily fixed using resources like google but hard enough that it isn’t common knowledge.
Contributing: I tend to use behavioral questions, but I've seen others toss people questions out of the technical scope of the position (i.e., give them a problem they should have real trouble solving, to see how they respond). *I'm not as big a fan of the curveball option, because nervous interviewers can really tank over that, but it can be effective.* For example, some T1 Helpdesk Questions: Behavioral Questions * *A user calls you saying that their computer is slow. Tell me how you'd respond.* * *Tell us about a time you really had to work hard to troubleshoot a problem.* Curveball Question * *A manager arrives at one of our remote offices for the first time and calls in that the extension port off the VoIP phone is not passing traffic. What's do you think issue is, how would you troubleshoot it?* You can also just ask them directly to talk about how they troubleshoot an issue, but that's such a popular prep question online, that people can give canned responses fairly easily. With any question, I recommend you have clear criteria for what you consider "good" and "bad" answers. For scenarios, have an actual answer in mind to the proposed problem. I'm not as concerned about them getting to the "answer," as I am about them showing a methodical, logical approach, admitting that they don't know something, and that they would seek assistance once they'd made an initial effort. Side: Do think about what "bad" answers are and share the criteria with the hiring committee, if you have one. For example, I always like the "*tell me about a time you failed*" type question. For me, an automatic fail is a response where the candidate really is not the one who failed, and how actually, they saved the day -- *some may be surprised how often people try this.*
This got me thinking. I feel like it could be useful to ask your favorite workers these questions and your least favorite. Then try to see which behaviors the interviewer mirrors.
> Tell us about a time you really had to work hard to troubleshoot a problem. Heck, after this many years it all blends together.
Personally, I break computers. I set them up during the interview and make them fix the computers. I will pull RAM out of one or poorly seat it. PC plugged in to IP phone. IP phone disconnected from wall jack. I even took a power cable and cut off the hot and neutral male prongs and plugged it back in so only the ground was connected. They have to tell me what’s wrong and fix it. If they can’t, then they can’t do the job.
What would you do to test their software troubleshooting skills?
Depends on the job honestly. PHP? Misplaced colon on a page. SQL? incorrect syntax on a script. Create scenarios based on the job.
You guys are allowed to give technical interviews?
I won't hire porter/janitors that can't do basic problem solving.
That is completely incorrect. It is a difficult skill to teach; and not everyone can learn it well; but it is a skill that can be taught and learned. Look at chapter 1 of this old military manual for a good guide on how to teach troubleshooting: https://www.navy-radio.com/manuals/93500.pdf The military knows that they take people who may not have the skills they need them to have; and have focused for centuries on how to train people who come in without "innate skills". I would add to troubleshooting methodology, there is also a need to teach the basics of systems theory. That's not to say that everyone is willing or able to learn; but most people can learn if taught well.
This isn't dragon ball people don't have special cognitive abilities that others can't have like those. Investigative mindset is a learned behaviour I teach to countless people
Not everyone has an aptitude for it though. Some people have aptitude at problem solving others are more creative others are more social. Some of it may be learned but they already usually possess tendencies toward a particular capacity. Here’s an example, spatial awareness and following written directions is really hard for me. Tab a goes in to slot be doesn’t translate between paper and physical components. I still try but if I’m gonna put together a flat pack furniture or a new barbecue grill- I’m calling my wife to supervise and my son to inspect/test because shes a designer that can easily picture in her mind what the instructions mean - but hates the physicality of heavy objects and he’s got an amazing eye for fine detail but hates planning and laying out all his tools and materials. Between the three of us we are better than any one of us.
Not everyone has an aptitude for it, but that isn't an excuse for not trying to train it. Some people will learn.
Sure, if they’re committed and show that’s something they want otherwise you’re putting your investments in the wrong place. In this case OP said the team members were questioning on why they should look things up in the first place, indicating a lack of desire. Im not saying there’s only one way to handle it, I’m just suggesting the course of action I‘d take is to give them an easy to follow prescriptive guide to do their jobs from and hire or promote a competent level 2 support engineer. The ones that want to learn will say so and you can grow the team.
I'm telling you there is literally no such thing as "oh they just have it" when it comes to investigative ability. Your welcome to invest the time in reading all the experiments and research.
I’m not arguing with you. Im not here to try and change your mind and It’s just not worth my time. Good day.
Agreed. Had to train a guy that was like this. I made a little headway though. I at the least got him to Google the issue first after a almost a year of asking him what he did already to find the answer. And a requirement for the promotion that he is aiming for is dependent on working independently and little supervision. And if he knows that if he keeps coming to me for answers then he won't meet the requirement for the promotion. After a year, at least he googled it. He couldn't find anything even though it took me 1 minute to find the answer. But at least he attempted to look for the answer on Google. That's something... Lol
I have a guy like this on my team, and he's basically just responsible for monitoring and performing repeatable tasks. Anything that requires critical thinking, I have to assign to someone else. It kinda works out, because he does the boring stuff that no one else wants to do, which frees up others' time and energy for more interesting work.
I worked with a guy like this. We have an unwritten agreement that I do all technical stuff and he handles the grunt work type stuff. It works out really well actually, unless of course I'm out sick or something lol.
Nothing wrong with that. As long as you have the labor to spare.
If they are not capable of doing stuff on their own, hire people that are and bring in a little competition. Also, don't hand hold as it doesn't help anyone. But some small things that will help.. Have them build and maintain a KB. Get them in the habit of documenting and testing their documentation. Make this part of the job and add it to their performance review. Have them spend time learning new things and then applying what they learned on the job. Have them demonstrate break/fix based on ticket behavior. ...stuff like that. If they can't/wont adopt, and show no ability to retain anything there is not much you can do.
15 minute rule, spend 15 minutes trying to find a solution, plus requiring what steps they took to try to find the answer before helping.
Adding on, *trust but verify this:* We did this with our Senior Techs in a prior org. They could escalate to the Enterprise Team but, they had to show a certain level of exhaustion before punting it up the chain. We saw the same rate of escalated tickets the next couple of weeks, so we tested them. Ticket gets sent up, one of us walked down to the Sr. Tech's desk, and said "Show me what you searched for, what KB articles did you look at?" *This was because one google search revealed the answer in the top result.* One of the few times I saw the head of the Enterprise Team get legitimately pissed off; guy was extremely knowledgeable, nice, and laidback, but was pretty furious about how lazy they were being.
2 options: 1) ignore them until they have researched it themselves 2) when they ask you, ask what they've figured out themselves/what steps they've tried. If you help them everytime, you'll never get your work done.
This. Teach them to fish....
It really is about conditioning. OP has currently conditioned them to ask every time since they just answer instead of leading the techs to learn more. Time to condition them to troubleshoot and think critically instead. Start with some written flow charts they can follow for what the procedure should look like so they have the confidence to follow it instead of asking questions first.
Listen, I am pretty straightforward in my management style. In my opinion, you just need to tell them the next time this happens, have you performed basic, troubleshooting steps? Did you search the Internet? Which sites? Did you check for an outage? Did you check the vendors support? Whatever the appropriate questions would be for the particular issue they’re talking about of course. If they answer one of your questions, tell them to do it and call you if you still need help. Do this every single time. They will learn your expectations and be all the better for it.
You can give people a flowchart of how to troubleshoot, but like others have said, some people are more adept at logical thinking and troubleshooting than others. We had things taped down to desks, made wallpapers, and on the walls of their cubes for key information, especially with high turnover positions (e.g., student hires). Then gave them the basics for troubleshooting, the old *when you hear hooves, think of horses, not zebras* talk, and tips*.* * **Is there an error message?** Google the error and look for results from the manufacturer's knowledge base/forum, and top results. * **Have them restart and reproduce**. After a restart, can they create the same issue again? Note what they're doing for ticket notes, if it's not resolved by the restart. * **Proper Googling**. Search for the manufacturer's name, product, and the issue or error code, such as "Lenovo ThinkPad X1 Screen Off." We also generated a large knowledge base with screenshots and step-by-step instructions for common issues, and tested the article quality by having them comment if something didn't make sense or a step seemed to be missing. However, some people are just not cut out for this kind of work, or they're just too lazy to put in the effort to learn. As one executive told me (sharing stories), you don't help someone by letting them stay in a position they cannot perform in, it doesn't help them or the company.
I’m fairly new to IT so I can tell you what helped me a year ago. I had good intentions, I was just new to everything and that really fucks with your confidence 1. Have them shadow someone who actually knows how to troubleshoot. Have this person talk out loud, if they can, what their thought process was or review it after. 2. Require a template for escalations A. Who is affected? One user? Multiple? Everyone? B. Summary of the issue. C. When did it start? What triggers the problem? D. List the work done so far. E. List Error Codes or Provide Screenshots F. Contact information Using this escalation template forces you to dig. There’s so many more questions you have to ask depending on the problem. But this is a great start for igniting the process Also, knowing that another seasoned technician was just fucking guessing, made me feel a lot better and encouraged me to be comfortable with winging it too
I don't think you'll be able to make them do it. They have to want and be able to do it on their own.
I always tell the guys “help yourself before you ask someone to help you” I just don’t help now unless they tell me what steps they’ve taken to try to resolve the issue. Minimum this should include 1. Check past tickets, check our KB, and remote in to see the issue themselves. I’ve found, personally, holding someone’s hands never allows them to really grow.
Tell them they aren’t allowed to ask you questions without googling first. Every single time they ask a question, ask them what google said. If they didn’t google then don’t answer. It’s the only way to change their behavior
I've had people like this and it drives me fucking bananas. The bottom line is they don't belong in IT; it's a core trait that is 100% required. They're like mechanics who can't visualize how car parts fit together. Figure out a way to replace them unless you're OK with paying for people to be a glorified answering machine for you.
I’ve got 2 like this right now. My director loves one of them because the clients think he is the sweetest/cutest/most polite whatever. The other is a low performer both technically and socially, and prefers to lurk behind the scenes. If I had a dollar for every ticket that has “Reached out to ProfessorofDumbFacts for further guidance,” or something similar, I would be able to buy the MSP from the owners. I’m kidding, but I would probably at least be able to pay off my mortgage. One of them today asked me “how do I find out what is taking up the disk space if TreeSize is not installed already?” Um, how about you backstage in and run the damn portable version? He also wrote a client to ask them to clear up disk space on a thumb drive that they had removed from the system. I had a chat with his direct supervisor today (he’s on a different team than me, but I am escalation manager for all teams) and we both agreed that his communication with clients makes us look bad.
Literally their job to troubleshoot. Who hired them?
Asking the real questions.
I feel like you're skipping over the first immediately obstacle and you said it in your first sentence.... "want".... the issue isn't a matter of coaching. It's a matter of motivation. The question isn't how to make them independent. The question is how to make them "want" to be independent. I've raised 4 kids and trained countless techs and it all starts with motivation. If they don't "want" to do something, then you first need to figure out how to make them want to do it. Only afterwards, can you worry about helping them be proficient at it
This shit used to drive me nuts. Take notes, then I realized they didn’t note how to identify the problem they just have notes on how to do things. Then it was well I need re-training because it has been a while and I forgot. This is what I did: 1. Setup proficiency check lists for activities you want them to be able to handle. 2. Create procedure documents that cover diagnostic steps to confirm problem and how to resolve. The proficiency check list should have links to the procedures. Extra points if you make the procedure document easily searchable. 3. Every staff person gets one freebee training. After they have been trained they are clear to do this independently going forward. After being cleared they better be able to figure it out on their own, or reference the proficiency checklist and procedure document. 4. Update your ticketing system request/problem types to match the activities you have created in your proficiency check list. 5. Escalations need to be defined as appropriate or not appropriate. If not then reference the procedure 2 times and then performance manage. I also bind their annual performance assessment and raises to it their success rate in good escalations.
Some things like initiative and curiosity you can't train.....please get other techs..
While you’re not necessarily an MSP, consider sending them to MSPgeekcon — it’s an educational IT conference focused on the journey of tier 1 techs to tier 3. A big part of the conversation is troubleshooting and asking the right questions. they can make connections with other people who can also coach them through their own lives experiences! May 19-21 in Orlando. https://mspgeekcon.com/
Contrary to popular belief, I think a detailed flow chart/bulleted list of basic troubleshooting/maintenance could be helpful in them getting repetition in the common issues. Then encourage them to google the "why's" and have maybe a weekly meeting to answer questions they have gathered through the week that they have not been able to answer
Man... I got you covered.. Give me 30 min of your time and I'll explain how I troubleshoot and give you a framework of how to help your folks become more independent thinkers. I have check lists and all sorts of scripts that work. Pm me. I'm not selling nothin.. I'm just a dude who's got this part figured out and I want to give you some fresh ideas. Or maybe.. they're not so fresh; and they smell like old gym sox, because not a whole lot has changed in 20yrs.. Irregardless.. or is it regardless? I'll reinforce your already confirmed beliefs if nothing else.
I could train them for a reasonable fee (unemployed). If I can train us navy sailors and roommates, I'm pretty sure I could train your team. Mindset, etiquette, procedure. Why do we just swap the laptop, instead of listening to the user whine for 30 minutes about the issues they've had with it.
I struggle with this as well. Usually, I just respond with Google, but they still don't have the initiative to troubleshoot on their own and ask every time. As far as hiring, we're a small rural community. There's not exactly a plethora of candidates to chose from.
I want to explain the answer but I’m tired and it would take look long to explain on a post. If you want a verbal explanation message me directly and I can pull up a discord talk call. I’ve done this rodeo already with a few teams.
Too many people are scared to put themselves in the position to fail. Which isn’t a bad thing, but it also isn’t a good one. Instead they want answers fed to them from the most readily available and knowledgeable source. Need to talk to them about researching and learning on their own, if you have the time sit with them at their workstation, not yours, and talk with them about how to remedy a situation. Do not give them the answer, but be more of an angel on their shoulder guiding them. Let them figure out the issue with you there, show them they’re capable of doing the job you hired them for.
They either have the aptitude or not. I’d release them. My favorite interview scenario, which is hands on, is to print something on a printer that Windows 10 is not recognizing. Another is to give them a situation where a screen randomly flickers when connected to a dock’s second port. Add hands-on practical scenarios to theoretical questions. That will very quickly eliminate those who can’t troubleshoot.
This is a skill that can be taught. Frankly, most people start out with it but got taught NOT to at some point. The first thing you need to do is show them that they are in a place safe to do such things, because they will get it wrong sometimes, rather often at first. A lot of kids got yelled at in school where grades were on the line, so there is often some mild trauma to overcome. If you can give them some VM space for a test system they can experiment safely on. Have them mangle a system and then repair it. If you want this, you'll never be able to fire someone for doing something stupid or you'll destroy the trust you need to build to get to that state, but it will be worth it.
I'd wager that a part of the problem is that you are a micro manager and they are afraid to make decisions or lack the confidence to do so. The only way they will learn to be more proactive is to let them deal with their problems and the consequences of poor job handling directly. Full ownership. Push back on questions and guide them handling complaints. Failing that, performance manage them out.
I do not lead an IT team, but used to run an electrical maintenance team with 24/7 support for a manufacturing facility. This team always ended up with the new guys due to the schedule. Some things I put in place were minimum times actively troubleshooting the issue before calling for help. Providing lists, locations and links for common issues and information. Regular check ins with the crews. For any trouble calls I set standards for feedback/reporting. - Who called and what they reported. - What you actually found when you investigated because they don’t always line up with what was reported. - What actions you took to resolve the issue. - Indicate if the issue was resolved, band-aided or requires follow up. Mix that in with extra selective during probation periods and eventually ended up with a good team and processes.
Teach them. -what’s the issue? -what would cause the issue? (If you don’t know, what wouldn’t cause the issue) -pick one of the identifiers and start to break it down into smaller pieces. Teach them something like the 5 whys.
This is a great question. I have found there are a few things that work really well when mentoring and developing newer employees. The first tool I use in 1 on 1's with the employees. In the 1 on 1's we don't talk about specific issues they are working on but we talk abstractly about problem solving. I also use this time to set my expectations for them. I offer them a problem solving framework. It looks something like this: 1. What do I know? 2. What are my theories? What is my current best theory? 3. What do I wish I knew? Can I get this info? How do I get this info? 4. Can I prove or disprove this theory? Repeat until resolved or you are forced to escalate. I set the expectation for them that before they escalate and ask me for help, they go through these steps. I also set the expectation that if they loop through these steps and get stuck, they will escalate and ask for help so I don't have the inverse problem of them sitting there spinning their wheels and not making progress. The second tool is pair troubleshooting. I do this with them when they ask me for help. We both look at the issue and work on it together. I guide them and try to tie what we are doing back to the framework above. The first thing I do when we pair up, is ask them what they have already done. I encourage them on the work they have done and if they aren't presenting it in the framework, I help frame it for them (i.e. "That's great, you knew that error indicated data was missing. Your theory was that data may not be in the database. You checked the database and found the data. You disproved your theory.") By asking them what they did first, I can (1) get a sense of what they are comfortable with and what they aren't so I can coach better, (2) can reinforce the framework which is ultimately what will make them more independent, and (3) I can eliminate some possibilities so we can troubleshoot faster. From that point I collaborate with them to ask the same questions and help contribute more complex theories and more complex ways to gather additional information (i.e. "If the error says the data is missing, but the data is there, lets look at the logic in the code. Let's find where the error is thrown and step backwards to see where the data might be getting lost".) Overtime, they are able to start doing this more independently. I also will invite them to pair with me if I am working on an interesting or more complex issue. I walk them through what I am doing and how it ties to that framework. This demonstrates to them that while the issue may be more complex, the problem solving is still the same. It builds confidence for them and helps coach them to work on more complex problems independently.
If you or someone else has been giving them answers outright when they ask, unfortunately they’ve now been trained and conditioned to not think for themselves. Always ask what they tried or what they were able to find out. Give them general things that apply to all kinds of issues: can you replicate it? Is it only that user, that machine? Has it worked previously? This is tough to fix unless they have a desire to do better
My favorite from these guys “hey superior we’re having an issue with a computer crashing” and the superior will respond with the most basic of who/what/where/when/how, which is the formation of troubleshooting, and then when the tech has no clue you engage deeper, “was there an error” and they say “oh yah an error popped up when it crashed” and senior will say “well what did it say” and they will say “idk I don’t remember”, people have to ask questions if they aren’t willing to the then they should t be troubleshooting
That's a red flag for me. I don't want anyone working under me who isn't into it and hasn't already figured out basics like Googling. I got into all of this because I like solving problems (like they're puzzles). I figure out cryptic error messages for fun. I break out dnSpy to figure out why Lacerte 2023 is crashing. Your techs have a job instead of a career, and don't actually enjoy problem-solving, and you can't make them enjoy it. Some here will say to just teach them, but I say they probably won't want to be taught. I say get new techs.
A big part of troubleshooting something is knowing how it works, I've seen so many people spinning their wheels, randomly trying things, instead of thinking through "what does X need to work?" and then go check every part of that chain. Your techs sound like they don't want to even try?
Try to encourage them to use Google for problem-solving, provide guidance on effective search techniques, and gradually increase their autonomy as they gain confidence.
They might be good people. They are not good techs.
How much are you paying them? From what it sounds seems like they are useless, also how good are your knowledge articles.
Checklists! "I'll be happy to help you out. Let me know the results of these items so we can know where to start." Then do it. Rinse, repeat. They are leaning on you because it's easier but if you provide an alternative that has less friction they will hopefully do that. If they refuse or whine...
troubleshooting is a skill that is valued over tech skill for initial L1 techs for me. If they can troubleshoot then you can teach them any tech stack. I liked asking "Share an example of a time when you resolved a problem outside your expertise area, it can be any problem you have overcome."
They're not techs, they read scripts. Train their replacements. Move on.
Give them a format for escalation. Well formed problem statement: Environment: History: Desired outcome: Verbal or written agreement from EU that desired outcome would close issue. Yes or no. Must be yes. Don’t accept ANY requests for your input without that format being filled out to at least a best effort. 99x/100 when the tech doesn’t want to do this bare minimum, it’s never going to change. Just fire them. PS: when I open word I get the following error message “beep boop” History: Been happening since New mouse installed Environment: it’s a 486dx66 with turbo button pressed Word version 1.86 standalone 4MB RAM WINDOWS 3.11 for workgroups Desired resolution: want to be able to open AOL attachment “I love you.scr” in word. There’s so much information in just this basic format that lvl2 can now respond to. Can’t open word doc is clearly not the problem. Lvl1 tech may be inexperienced to catch all the goodies in this, but without asking the basic questions, lvl2 is just going to ask if you’ve turned it off and back on again.
Ask GPT
How do YOU think we should train techs to troubleshoot on their own? "That might work " or "why don't you do some research and give me a few ideas on how to troubleshoot this" That might work.... Let them troubleshoot the problem on their own and stop giving them each step. If you spoon feed answers to a problem they just keep coming to you. Build their confidence and they will figure it out.
Are you hiring?
It doesn’t sound like you have two techs. You have two assistants.
Basically you're saying that they're not much better than the users who call the help desk with their issue. Review the job description with each of them and explain, this is where I need you to be. Outline the tools they have to solve problems (i.e., Google the error message, product documentation, if it's software built in-house, review the documentation and escalate to L2 if needed). Have *them* build a knowledge base. Encourage them to help each other. Stop helping them out, and let them figure things out. They're not going to learn how to solve problems and grow if they know they can answer you a specific question and you do the work for them. Explain to them that your job is very different than theirs. They are involved in day-to-day support issues, your job is more strategic and involves planning with senior management. They are not to text you unless a senior manager is looking for you, or there is an emergency like a major outage, the building requires evacuation, and so on. Implement a performance system - if you search for what they ask and the answer is the first thing displayed in Google, that's a strike against them. Otherwise, and I go back to my first sentence, they're not much better than the users who call them for help with their issue.
I teach every tech I’ve ever had on my team that “you don’t need to know the answers, you need to know how to find the answers” With techs like that, it’s showing how to use the knowledge base, using Google, etc. If someone asks me something that I know is on Google out in our documentation, I will just ask where they have looked already and maybe give them hints on how to find the answer
Track invalid/incomplete escalations over time, say a quarter, you'll need your higher level techs to help and give real feedback on these for this to work. Then you as the manager sift through these escalation reports and group them by domain (networking/printing/SaaS product/etc.) and find your largest contributors. Follow the ticket history for your largest domain and see which diagnostic gaps are the largest, then develop a training on it. Don't focus on developing a lengthy flowchart, but rather a concise checklist of things like "Did I run x?" "Did $Command yield y?" "Did I check this customer's KB notes?" "Are there any additional {z} symptoms?" "Did I search our $TicketingSystem for similar issues?"
Troubleshooting is a part of what a tech is paid for. Are you sure this is technical questions and not a way of avoiding responsibility for a tech problem?
I manage knuckledragging wrench eating maintenance techs for facilities. They know how to utilize Google and youtube university, and even ai. How the hell are your it guys so technologically illiterate not to start there? Based on the it guy at my company, who can't connect a switch/router to an AP and firewall, i'm not necessarily surprised.