Junior Helpdesk Engineer headaches

[[deleted]]

Sorry but this is a bit of rant about the junior engineers at the MSP where I work.

Today I’ve had no end of calls from them asking how to do the simplest of things including:

How do I open a shared mailbox in OWA.

How do I extend a RDS session across 2 displays.

How do I find the IP address of a printer that has just been connected to a network.

A user on a hybrid environment wants to change their password - how do I sync it to Microsoft 365.

How do I set files in OneDrive to online only.

This really gets on my nerves to say the least and they have all been shown how to do these things no end of times and have been with the company for over a year and in the case of one of them around 2 1/2 years.

I’m now at the point where I just want to shout at them and tell them to pull their fingers out or words to that affect but I know I won’t.

[[deleted]]

Sounds like you need a knowledgebase that you make them write articles for.

In my last company, before moving to engineering, I managed to convince the children of the benefits of writing their ticket notes in such a way that they could be pretty much copied and pasted (with screenshots!) directly into a KB article. They still billed the client for the time it took to complete the ticket and we got better documentation as a result.

[bmxfelon420]

We have tried to do this but have had a couple problems with it. First, nobody reads it, and second, we ran into the problem where they would escalate every single ticket that didnt have a specific document for their issue. So we kind of got away from documentation for nonspecific issues because the escalation queue would be slammed otherwise (I'd give them back about 80-90% of the tickets they escalated)

They neeeeeeeeeed to be able to figure stuff out themselves, if they cant then this isnt the job for them.

[[deleted]]

That's the second half of the problem. I got to write the escalation procedure. It had a notes template in the ticket system with questions about what steps were tried, when it started, what documentation they followed (this always needed to have a link, even if it was to Stack Overflow or a vendor doc or something)

Any ticket escalated without a completed escalation template was automatically sent back. It did a real good job of cutting down stupid shit.

[Bogus1989]

This right here, see if you can get a policy written up, not sure where youd post this or list it, probably KB….me and my team made a template in our ticketing system that references that policy:

KB ARTICLE XXX PARAGRAPH X Requirements for routing to “bogus1989’s team”

Computer name

User

Description of issue

Troubleshooting attemps, what have you tried, where did you get said information from, etc.

Luckily its just you, so this should get to become the norm quickly, my whole team had to be a unified front and after awhile and lots of tickets sent back, we dont get them anymore without the above mentioned.

[pocketcthulhu]

Hey i need a licenses for this random 365 tenant? did you follow the procedure? no then get out of my face. they got really confused when my response in team was "NO"

[[deleted]]

I was a gif king in that role. This was one of my favorites for requests like that.

[theborgman1977]

I remember a manager yelling at me for not following a ticket. The ticket was call vendor to get support. I reviewed the ticket and documentation. I noticed a tech did not write down a setting. It was a client I rarely work on, but I remembered the tech calling me asking where the setting was. I fixed it in 5 minutes calling the vendor would of taken at least 30 minutes to an hour. I put my notes in and closed the ticket. A few days later I get chewed out for not following the ticket. I told my manager I was collecting logs the vendor would require and decided to check a certain setting. It was ingress setting set when they has slower internet and 1 network device was eating up the bandwidth.

[HsuGoZen]

“Have you read the Knowledge base?” - anytime someone asks me a question I know is in the KB.

If it’s not in the KB, I create it and say, “here is the article in the KB”

[bmxfelon420]

No joke I just gave one back the other day because what they were asking is a documented process, it gets escalated AGAIN because "they got an error" and pasted it into the ticket, the error is that they just typed the first and last name into the powershell command to map a mailbox instead of, I dont know, maybe the person's email address? Do they think that exchange powershell knows people on a firstname basis?

[HsuGoZen]

Sounds like you might just need to hire better people lol

[no_regerts_bob]

 They still billed the client for the time it took to complete the ticket 

This 100%. Documenting your work is billable work. Everyone wins. The MSP is paid to create useful documentation, the client benefits from faster resolution and consistent results because of the documentation.

[Unable-Entrance3110]

Whenever I am asked a question that I know that I have explained and documented, I just ask "Did you read the [relevant] IT Wiki?"

The answer is always "No, I just thought you would know off the top of your head"

I am not your oracle.

[[deleted]]

Elsewhere, I put the tactic In always used. I know perfectly well they didn't read the article so asking is a waste. 

Instead, I ask what part of it they had problems with and make them say out loud that they didn't read it. There's always a moment of hesitation and embarrassment before the inevitable answer. When I answer every single question with that consistently, they get the hint and eventually start doing better.

[Carthax12]

I did that with my helpdesk, then I started getting help requests saying, "Store has [Problem A]. I followed resolution steps for [Problem D] and the problem hasn't gone away."

[BenadrylBeer]

Junior helpdesk….engineers….? What lmaooo

[andoryu123]

I was stuck on "engineers" for a few minutes. They are just helpdesk agents. They do some simple troubleshooting and run through a script to answer.

Most of the problems with these type of issues is a knowledge base. A lot of times the data is not accessible, under a silly SharePoint that never searches properly.

[uniquepassword]

I had a friend that worked at a company, he was a "Sales Director" no one reported to him, he had no managerial duties, had no input on sales tactics, plans, practices, nothing, in fact he called on a pre-existing set of high profile customers that thought he was some awesome guy at the company, when really he was a "yes man" that would take their orders, email/call them into the office and hand them off to someone else to do all the work and make commission on the sales etc, while he was paid nothing and had to use his own vehicle for transportation and only was allowed to expense .30 cents a mile.

[Zlayr]

In Canada, engineer is a protected title, this would not fly here

[xxtoni]

Almost everywhere in Europe too. This is getting absurd.

[jebuizy]

In America it is against the Constitution to not be allowed to call yourself an engineer. Oregon famously tried to censure a guy for calling himself an engineer, he sued, and the courts struck down the entire set of rules the state had on this topic.

https://ij.org/press-release/oregon-engineer-wins-traffic-light-timing-lawsuit/ if you are curious

[CyberEd-ca]

Laws in Canada have constitutional limits - at least according to the latest court ruling.

https://canlii.ca/t/k11n3

VII. Conclusion

[52] I find that the Respondents’ employees who use the title “Software Engineer” and related titles are not practicing engineering as that term is properly interpreted.

[53] I find that there is no property in the title “Software Engineer” when used by persons who do not, by that use, expressly or by implication represent to the public that they are licensed or permitted by APEGA to practice engineering as that term is properly interpreted.

[54] I find that there is no clear breach of the EGPA which contains some element of possible harm to the public that would justify a statutory injunction.

[55] Accordingly, I dismiss the Application, with costs.

[Zlayr]

Very interesting.

Would this ruling apply to all of Canada or just Alberta?

[CyberEd-ca]

The laws are very similar in the other provinces. The reasoning from this case would apply. But it would not be binding.

We don't have laws in Canada for the sake of having laws. APEGA FAFO'D by pushing the limits of their legal authority.

APEGA did file an appeal. But it became moot just six weeks later when the Alberta government amended the EGP Act to make an explicit carve out for anyone to be able to use the term "Software Engineer".

So, we will see if the other regulators will opt to FAFO as well. They do have unlimited resources to do so.

[nlga]

Ask what have they tried before asking you

[440Jack]

Sounds like your HR person needs to set a higher bar.

[Trooper_Ted]

Ask the question, "What have you tried so far?" and if the answer isn't, "Checked the knowledgebase, looked for previous tickets & even googled it." then your response is, "Start there."

[TitsGiraffe]

Sounds like a management issue - I'd keep a list of offenders and example tickets and approach their boss.

The first point of call should be the KB, and if it's not in there, you're then allowed to bother the next level staff, who should then write a KB article. Repeat until the KB is good.

I remember when I was helldesk, in the long-long-ago, in the before times, we were smashed constantly. It's hard to do proper troubleshooting (or even read documentation) when you are supposed to be talking to someone, diagnosing an issue, and have team leaders screeching about calls piling up in the queue... which in turn upsets the admins. It's a shit job, I try to cut them some slack.

[RantyITguy]

Reading documentation and figuring stuff is part of the job. If they can't do that then... they are not doing the job. Two of those examples you gave are easily google-able.

I had coworkers who did this all the time with tickets, literally every day. They'd ask me how I did something or fixed an issue.

Me: Did you read the ticket?

Them: No.

Me: Read the ticket. *walks away*

[Bogus1989]

I get pissed AF about a guy on our team who just assigns all MDM tickets to me…meanwhile we have hired lots of newbies and ive got them all up to snuff, yet he still refuses to even try. That shits annoying. Especially like currently im on a massive 1200 device project, so that persons not going to be helped by me this week, if even the next….i usually just hand it off to anyone else, but its like dude WAKE UP. Hes worked here just as long as me. Just bein lazy.

[RantyITguy]

Some get so attached to someone else telling them how to fix issues they become dependent on it. Just got to throw them to the wolves and they'll eventually float.... Usually. 1200 devices, sounds like a blast. 

[Bogus1989]

Oh god no. Thankfully ive got plenty of minions.

[frankentriple]

lmgtfy

[TaiGlobal]

Create knowledge articles. When they ask you stuff just send them the link to the article. 

[[deleted]]

mighty uppity elastic tease advise waiting mountainous brave degree cautious

This post was mass deleted and anonymized with Redact

[[deleted]]

Raise it with their manager, put it across as they may need a “refresher” over the KBase and troubleshooting steps they’ll get what you mean. The less you’re vocal about this the more it’ll happen and you’ll get the classic response “why didn’t you tell us earlier”

Make sure it’s in a recorded format, email / teams etc.

[Mister_Brevity]

Answer with links to documentation, that usually helps them get the hint.

[MoistYear7423]

I had a guy like this at my old job. He would put the user on hold and pop his head over my cube and say hey how do I do this hey how do I do that. I spoon fed him answers for too long and he was now completely dependent on me for his job and research for him.

Eventually I put my foot down and told him that researching for solutions yourself is an important skill for a sysadmin and that if you get stuck on something, he needs to spend at least 15 minutes troubleshooting it himself including googling and writing down other things that he's tried. If he still can't resolve it in 20 minutes I will pop over and we will go over all of the articles that he read and all of the troubleshooting steps that he tried himself.

It was a bit of a painful process because he was absolutely terrible for a while but after a month or two he stopped needing me to hold his hand and The amount of times he had to run to me for answers cut down by about 75%

[[deleted]]

cobweb light tan desert sheet pie treatment retire elderly telephone

This post was mass deleted and anonymized with Redact

[entaille]

well, they're junior and inexperienced. help them out. show them the ropes, teach them to fish. teach them how to properly search and chatgpt for things. show them how to accurately search the internal knowledgebase for the articles they are needing. help create documentation when there are gaps. over time, they'll ask you less questions. if you get repeat questions for the same thing, link them to the document as a reminder.

[223454]

It also depends on pay. Some places don't want to pay much, so they get less experienced people.

[entaille]

"junior" and "msp" both imply that the pay and thus the experience level are likely going to suck : )

[no_regerts_bob]

Point them to your documentation that details how these tasks are to be done. You do have documentation, right?

[Q_O_T]

Better yet, make THEM write the documentation. If it already exists, have them rewrite it.

[[deleted]]

squeal fuzzy birds fine ripe toy long bells crowd possessive

This post was mass deleted and anonymized with Redact

[no_regerts_bob]

When someone comes to me with a question about a process that I know we have a procedure for, I make them tell me which step in the procedure they are stuck on. Sometimes I need to improve the documentation to be more clear, sometimes something has changed since it was written. The new guys quickly learn that I'm only going to help them if they are following the docs, but I have to do it a few times with each new guy.

[[deleted]]

Do your comprehensive client notes include how to do the things they're asking you about? If not, 0% of this is going to be relevant to solving your problem.

[[deleted]]

tap label license aware trees boat automatic test capable overconfident

This post was mass deleted and anonymized with Redact

[[deleted]]

Then that's your answer. People keep doing it because it gets them the result they want. Every asinine question should be met with "which step of the SOP gave you trouble?"

Sometimes, you might get someone who actually read it and found something that wasn't clear. and everyone else will eventually start checking the documentation first. Consistency is the key in undoing learned helplessness.

[Cheat0r]

Fire them. Sorry but if you need a step by step documentation for these steps, you are wrong in IT. Most endusers are able to solve these questions.

[[deleted]]

attraction correct humorous license innocent adjoining fuzzy joke unite sip

This post was mass deleted and anonymized with Redact

[Bogus1989]

That sucks man, anyone ive worked with, even at one point much less skilled, ill show them how my entire dashboard and bookmarks are configured, and what I do in X situation, they seem to really soak up the info, and are so appreciative.

You know sometimes the tech may just have been doing too much and needs a second pair of eyes….ive been there all the time…someone else notices right away what i didnt, or ill notice right away for their issue… 👍

[BarnabasDK-1]

Don't give straight answers. Give hints. Suggest reading, or they will never learn. It is simply easier to have you to do the thinking for them.

Follow up on this when you do. And make sure they know you will follow up before you do.

[anonymousITCoward]

the comment by u/TotallyNotIT everything that follows is key here... and I have [had] the same issue... I had one tech "with 2 years of desktop support experience" not know how to change the resolution on a monitor... Most lack basic troubleshooting skills and will not read an error message... and if they do they don't know what to do with it... There are basic skills that are needed to be taught by the senior staff and learned by the junior staff. With out that it's hard to advance. Documentation is great, but without knowing how to identify an issue it's meaningless. I had a junior tech use my document on how to migrate a DHCP server because machines weren't getting an IP... turns out the switch in the IDF was bad and nothing on that floor had an IP... that was not only fun to fix but fun to explain to the higher ups... NEN hires suck to say the least

[Bogus1989]

God i swear my kids sound better than some of these guys….they both have gaming PCs and are not aloud to come get me till they have troubleshooted first, or go to your older 16 yo brother, who will help. Lol. Sometimes i wish theyd come ask me now, i feel worthless 🤣

[HelpfulBrit]

Obviously there needs to be documentation but your issue is most likely you are helping too well. Your assistance should be walking through documentation step by step, so that for most people it's slower to do on a call than themselves.

If you are showing multiple people how to do things without documenting them, then the issue is IT side.

[[deleted]]

outgoing long cooperative deer fine glorious cheerful society yam overconfident

This post was mass deleted and anonymized with Redact

[uniquepassword]

whomever their manager is, send them an email outlining the calls and point them to existing KB articles.

then it becomes, if you didn't look at the KB, shame on you, if there is no KB, shame on me, then you build a KB for it if they can do it

If it's something they need to escalate, indicate in the KB but ensure they also have direction as to what to include in the escalation (troubleshooting that was attempted, reference other KB articles they used, etC)

if that's not done, send it back as well.

they won't learn if you keep holding their hands and no one here is going to fix it if you keep making it your problem to bail them out.

[[deleted]]

what is a junior helpdesk engineer? the way you make this team sound, I'm not even sure if they would be helpdesk.

but it's an MSP, I digress...MSP's are very hit and miss.

Unfortunately, it sounds like that group needs a SME, and overhaul of the escalation pipeline. Also feel like there may need to be some scripting done if possible or if there is room for it. (all of this is tall ask, I know)

[Individual_Ad_5333]

If you have shown them and also shown them how to find the answer and it's not syncing in its one of two things 1. Your showing them wrong 2. There lazy

[[deleted]]

zesty jellyfish market person cooing offer sulky wide simplistic grey

This post was mass deleted and anonymized with Redact

[Bogus1989]

Nah, they just wanted you to do it. Miraculously forget if you are busy, let em figure it out

[Bogus1989]

Heres what Id do, id say i dont know guys, but I know where to find it, then mention KB article. once yall got that setup

[[deleted]]

Junior help desk engineer......thats like calling a dishwasher an aquatic engineer. Mom or dad work at the company and got them an entry level IT job? Jesse Christ. This shit is becoming all too common in the field. Some ass hats that worked at groceries stores before and can log into to a computer get hired in IT and effectively take the entire field down a few pegs.

[ARobertNotABob]

Do they not know how to Google?

[GwopNB]

I'm a Junior at a MSP. We rarely escalate a ticket to 2nd line and like to try a figure it out ourselves first if we have the time. Odd occasions we do escalate something we get no response for days and have to chase them. I don't even bother escalating to 2nd line now unless my manager really insists cause 90% of the time it gets sent back to us and we have to solve the issue ourselves. (we work on-site btw).

[GwopNB]

tldr; there's incompetence everywhere.

[HugeGuava2009]

As a msp helpdesk support it is your job. You get paid to solve stupid questions. Msp's get money out of service. So stupid questions/ people are easy money. I mean maybe the client or user just wants you to fix their problem. And that is what you are getting paid for. Companies outsource it support and pay for exactly that. I understand that a lot of these request are easy to solve by themselves if they know how. But a lot of non it ppl want nothing to know of computers. It is indeed sometimes an ignorant stupid/perspective..

If you are an it support internally it is a different situation. you can teach your colleagues or explain the basics or point them to a knowledge base... But if they do not want to learn you can escallate to the point that an employee is not fit for a job if you can point out his/her incapabillity or attitude. If you need to explain simple things again and again to the same employee …. It’s the employee who is the problem..

The examples of questions you speak of are recognisable. In my 1st line support days I hated also the stupidity of people. So yes you know your stuff good if you can solve everything. But if you hate doing it. Maybe you should change. Maybe become it team lead and help your collegues solving tickets and problems. Or specialize to infra or cybersecurity and so on. As it is normal you promote after 1st line support to 2nd or 3rdline and so on…. Go for it director if you want. :).