What is it like to work in IT support?
August 13, 2022 6:31 PM Subscribe
Pretty much what it says on the tin. Context below the fold ...
I've been working on making a career switch away from academia for a while and have been offered an opportunity to do a free short course in IT support work, followed by a paid short-term work placement. This is part of a government program where I live that's trying to help people to switch into tech-related jobs mid-career, where you shortlist a few kinds of jobs you want to be trained for – IT support was one of my lower preferences, hence I'm a little uncertain whether to take up the offer.
What is the work (and work environment) like on the ground? I feel like I have the necessary technical, problem-solving, and communication skills to do it, but I'm curious about the day-to-day. One thing I'm worried about is stress levels – in the teaching-focused work I'm doing at the moment we're essentially always in crunch mode without many windows to take a breath. I don't want to replicate that.
Thanks for your help!
I've been working on making a career switch away from academia for a while and have been offered an opportunity to do a free short course in IT support work, followed by a paid short-term work placement. This is part of a government program where I live that's trying to help people to switch into tech-related jobs mid-career, where you shortlist a few kinds of jobs you want to be trained for – IT support was one of my lower preferences, hence I'm a little uncertain whether to take up the offer.
What is the work (and work environment) like on the ground? I feel like I have the necessary technical, problem-solving, and communication skills to do it, but I'm curious about the day-to-day. One thing I'm worried about is stress levels – in the teaching-focused work I'm doing at the moment we're essentially always in crunch mode without many windows to take a breath. I don't want to replicate that.
Thanks for your help!
The hardest thing about support is that everywhere is different, so generalizations are tricky. In general, the job itself is not too difficult. It’s possible to get hired some places off the street with no experience. If you’re reasonably intelligent and/or familiar with how computers work, you should have no trouble succeeding. The day-to-day, though, can vary significantly from one company to the next, and even within companies. A lot of it will depend on your manager (and your manager’s manager). If they’re obsessed with performance metrics, you’ll burn out fast. But there are also some really good managers, who understand that it’s essentially a problem solving occupation, and each problem might have a different solution.
The biggest thing that sucks about it is that it’s a low-pay, low-prestige position. You aren’t going to make a ton of money, and nobody is going to be impressed by your job title, especially within your company. That said, it’s a great foot-in-the-door position. It’s how I started my career, and my job now pays pretty well and is respected enough. Took a while, but now I’m doing pretty well. One of my co-workers started on the help desk, and now he’s the system architect for the whole company. If you’re good, there’ll be opportunities to move up.
I’d be interested to know what your higher preferences are, and why. If you’d like to be a programmer to be able to use some degree of creativity in your work, support will be unsatisfying.
posted by kevinbelt at 7:33 PM on August 13, 2022 [3 favorites]
The biggest thing that sucks about it is that it’s a low-pay, low-prestige position. You aren’t going to make a ton of money, and nobody is going to be impressed by your job title, especially within your company. That said, it’s a great foot-in-the-door position. It’s how I started my career, and my job now pays pretty well and is respected enough. Took a while, but now I’m doing pretty well. One of my co-workers started on the help desk, and now he’s the system architect for the whole company. If you’re good, there’ll be opportunities to move up.
I’d be interested to know what your higher preferences are, and why. If you’d like to be a programmer to be able to use some degree of creativity in your work, support will be unsatisfying.
posted by kevinbelt at 7:33 PM on August 13, 2022 [3 favorites]
Really depends on what you mean by "IT support," which could be anything from a grunt-level, read the scripts, get the folks off the phone as soon as possible type job all the way up to a highly skilled troubleshooter type role.
My guess, though, is that this is more of a call center role, where you'll be measured and monitored down to the second and everything you do is tracked, analyzed, and evaluated. Call center jobs are very low paid, very stressful, and the industry as a whole has a very high turn over. To paraphrase something you've written, you will always be in crunch mode with no window to take a breath.
It is possible to get a foot in the door from these kinds of roles - that's what I did. But if you're looking for a job where you get to sit and think and solve complex problems, this probably won't be that role.
posted by ralan at 7:36 PM on August 13, 2022 [3 favorites]
My guess, though, is that this is more of a call center role, where you'll be measured and monitored down to the second and everything you do is tracked, analyzed, and evaluated. Call center jobs are very low paid, very stressful, and the industry as a whole has a very high turn over. To paraphrase something you've written, you will always be in crunch mode with no window to take a breath.
It is possible to get a foot in the door from these kinds of roles - that's what I did. But if you're looking for a job where you get to sit and think and solve complex problems, this probably won't be that role.
posted by ralan at 7:36 PM on August 13, 2022 [3 favorites]
If I were in charge of the world, in the impractical and arbitrary way I suspect we'd all like to be in charge of the world, people would get conscripted into the service industry instead of the military. "An armed society is a polite society", what a pile of nonsense. You know what makes a polite society? Everyone spends a year either cleaning up public spaces or picking up the trash or conscripted to work retail or food service, just so know what that's like, just so you've been on that side of the counter. Or you could spend that year doing IT support, for some opaque service or piece of software that is impossible to love.
A year in IT support will teach you more about computers and the humans in front of them than you will learn in any course from any school. IT support is not really about the tech, though you need to understand the tech - which is learnable, as Theora55 says, and in fact not super challenging - in most mature organizations, you'll have a set of flowcharts that manage 95%+ of the problems you'll run into, and a surprising number of the rest will be solved with a reboot. Much of the modern computational practice is fundamentally incompatible with the reality that consumer-grade hardware is trash.
IT support is about listening to confused, anxious, often angry, often frightened people, who are using computers not because they want to or care at all about computers or computing or literally anything involving flattened sand and the ghosts that animate it, but because they want to keep their jobs and a roof over their heads and who have called you at a time when that flattened sand has failed them somehow in some incomprehensible way they are powerless to resolve.
Software is basically distilled power. It is a set of decisions about what happens to the users of that software, that the users have, typically, no say in but are totally dependent on. You're going to have to know, or figure out, how to be patient and kind walking people through solving a problem you've solved for other people a thousand times, that would not be a problem for you at all, that is often fundamentally, existentially terrifying for the person on the other end of the call. Your job in IT support will be to answer calls from powerless, frightened people who might be having the worst day they can remember, and help them recover some sense of control over their situation without injury to their dignity or sense of self worth.
And sometimes, you'll have to do that while assembling a common language with a total stranger on the fly, somebody trying to describe what they see on the screen with whatever words they have to hand.
Theora55 isn't wrong - the field is ageist, sometimes sexist, and it is deeply undervalued by people who aren't very good at their jobs. It's difficult to find a place where the incentives are "the customer is happy and the problem is solved", rather than "you answered X calls in Y time" - the corollary to that is that you should ask some hard questions about how success is measured and what sort of career and workplace culture that generates. This is where you'll learn if it's crunch-all-the-time or not.
But as a starting point for a career change, and a place to learn an awful lot about the interface between the people and the tech (which is where all the action is anyway) and how it actually works when the rubber meets the road, you could do a lot worse.
posted by mhoye at 8:02 PM on August 13, 2022 [21 favorites]
A year in IT support will teach you more about computers and the humans in front of them than you will learn in any course from any school. IT support is not really about the tech, though you need to understand the tech - which is learnable, as Theora55 says, and in fact not super challenging - in most mature organizations, you'll have a set of flowcharts that manage 95%+ of the problems you'll run into, and a surprising number of the rest will be solved with a reboot. Much of the modern computational practice is fundamentally incompatible with the reality that consumer-grade hardware is trash.
IT support is about listening to confused, anxious, often angry, often frightened people, who are using computers not because they want to or care at all about computers or computing or literally anything involving flattened sand and the ghosts that animate it, but because they want to keep their jobs and a roof over their heads and who have called you at a time when that flattened sand has failed them somehow in some incomprehensible way they are powerless to resolve.
Software is basically distilled power. It is a set of decisions about what happens to the users of that software, that the users have, typically, no say in but are totally dependent on. You're going to have to know, or figure out, how to be patient and kind walking people through solving a problem you've solved for other people a thousand times, that would not be a problem for you at all, that is often fundamentally, existentially terrifying for the person on the other end of the call. Your job in IT support will be to answer calls from powerless, frightened people who might be having the worst day they can remember, and help them recover some sense of control over their situation without injury to their dignity or sense of self worth.
And sometimes, you'll have to do that while assembling a common language with a total stranger on the fly, somebody trying to describe what they see on the screen with whatever words they have to hand.
Theora55 isn't wrong - the field is ageist, sometimes sexist, and it is deeply undervalued by people who aren't very good at their jobs. It's difficult to find a place where the incentives are "the customer is happy and the problem is solved", rather than "you answered X calls in Y time" - the corollary to that is that you should ask some hard questions about how success is measured and what sort of career and workplace culture that generates. This is where you'll learn if it's crunch-all-the-time or not.
But as a starting point for a career change, and a place to learn an awful lot about the interface between the people and the tech (which is where all the action is anyway) and how it actually works when the rubber meets the road, you could do a lot worse.
posted by mhoye at 8:02 PM on August 13, 2022 [21 favorites]
I started off in IT support when I got out of library school and it's still one of my favorite jobs but, as people have said above, it can be highly variable. I really liked helping people and I am very good at troubleshooting. A few things to consider
- in person, phone, or email support? It can make a huge difference. I can handle a lot of stuff over email that is harder over the phone. And in person is great in some ways (you can see what's up, could also be true with remote desktop stuff like Team Viewer) but sometimes people are... hard.
- status of IT support within the org. It's better to do this sort of work when you're well supported and not just like a front line worker who is supposed to absorb customer wrath so that higher level IT support doesn't have to. It's also better when, for example, if you notice something that is wrong you can actually change it, file a bug report or something,not just have to tell customers you're sorry 1000 times a day for a thing that is going to stay broken.
- better pay can make up for some other job issues. IT support s often lower paying within an organization than programmers/developers, but it's still IT work so pays better than retail and depending what you did in academia, possibly equivalent.
So the thing that you are concerned about, the constant crunch mode thing, is a real concern but it can depend within an organization what kind of workplace you're in. Some places have punishing metrics, others are a lot more chill or let you work at a pace that works for you.
Your job in IT support will be to answer calls from powerless, frightened people who might be having the worst day they can remember, and help them recover some sense of control over their situation without injury to their dignity or sense of self worth.
This is a great summary. Not every IT support situation will have mission-critical types of situations but some of them will. Sometimes you're just doing help-deskish stuff like helping people using non-critical software better, or follow a troubleshooting script for something not-that-consequential. Short self-link: I do some library-based tech support with people who are (often) digitally divided and I maintain a very long Twitter Moment about it, you're welcome to read along here.
posted by jessamyn at 8:10 PM on August 13, 2022 [4 favorites]
- in person, phone, or email support? It can make a huge difference. I can handle a lot of stuff over email that is harder over the phone. And in person is great in some ways (you can see what's up, could also be true with remote desktop stuff like Team Viewer) but sometimes people are... hard.
- status of IT support within the org. It's better to do this sort of work when you're well supported and not just like a front line worker who is supposed to absorb customer wrath so that higher level IT support doesn't have to. It's also better when, for example, if you notice something that is wrong you can actually change it, file a bug report or something,not just have to tell customers you're sorry 1000 times a day for a thing that is going to stay broken.
- better pay can make up for some other job issues. IT support s often lower paying within an organization than programmers/developers, but it's still IT work so pays better than retail and depending what you did in academia, possibly equivalent.
So the thing that you are concerned about, the constant crunch mode thing, is a real concern but it can depend within an organization what kind of workplace you're in. Some places have punishing metrics, others are a lot more chill or let you work at a pace that works for you.
Your job in IT support will be to answer calls from powerless, frightened people who might be having the worst day they can remember, and help them recover some sense of control over their situation without injury to their dignity or sense of self worth.
This is a great summary. Not every IT support situation will have mission-critical types of situations but some of them will. Sometimes you're just doing help-deskish stuff like helping people using non-critical software better, or follow a troubleshooting script for something not-that-consequential. Short self-link: I do some library-based tech support with people who are (often) digitally divided and I maintain a very long Twitter Moment about it, you're welcome to read along here.
posted by jessamyn at 8:10 PM on August 13, 2022 [4 favorites]
I worked in IT Support for about 25 years, before I retrained as a librarian.
The work is mostly a mix of thinking logically, and reading instructions.
It can be a very stressful job. You spend a lot of time fixing problems, the problems happen at random, and sometimes those problems are really big problems. I've read horror stories about companies where there was only one IT person, and they were on call 24 hours a day, and never allowed to take leave.
On the plus side, it can be very satisfying when you solve a problem. And there's a buzz that comes from helping people.
Reddit's Tales from Tech Support forum will give you an idea of the (more amusing) things that happen on the job.
And Twitter user SwiftOnSecurity works in information security now, but they started out on a helpdesk and have some thoughts worth reading on the value of support work.
Two more resources, to give you some perspective:
- What I Wish I Knew Before Working in IT Technical Support
- 10 signs you may not be cut out for a support tech job
Finally, if you're wanting to leave academia itself, but still like the university environment, you might consider working towards something like Research Data Management.
posted by davidwitteveen at 1:32 AM on August 14, 2022 [1 favorite]
The work is mostly a mix of thinking logically, and reading instructions.
It can be a very stressful job. You spend a lot of time fixing problems, the problems happen at random, and sometimes those problems are really big problems. I've read horror stories about companies where there was only one IT person, and they were on call 24 hours a day, and never allowed to take leave.
On the plus side, it can be very satisfying when you solve a problem. And there's a buzz that comes from helping people.
Reddit's Tales from Tech Support forum will give you an idea of the (more amusing) things that happen on the job.
And Twitter user SwiftOnSecurity works in information security now, but they started out on a helpdesk and have some thoughts worth reading on the value of support work.
Two more resources, to give you some perspective:
- What I Wish I Knew Before Working in IT Technical Support
- 10 signs you may not be cut out for a support tech job
Finally, if you're wanting to leave academia itself, but still like the university environment, you might consider working towards something like Research Data Management.
posted by davidwitteveen at 1:32 AM on August 14, 2022 [1 favorite]
Everywhere I have worked in IT, there appeared to be a decent promote-from-within attitude towards the help desk; if you succeed, you rise quickly and may soon move out to another role. This fuels the perception that the help desk folks are never the best at their jobs because the good ones get promoted, the bad ones leave or get fired, and the rest just slog along because they like the work or something else about that job just suits them. So there can be high turnover.
Also, help desk roles can often be the first ones outsourced if a company decides to cut costs by divesting themselves of IT people (this trend is definitely on the uptick).
posted by I_Love_Bananas at 4:02 AM on August 14, 2022 [2 favorites]
Also, help desk roles can often be the first ones outsourced if a company decides to cut costs by divesting themselves of IT people (this trend is definitely on the uptick).
posted by I_Love_Bananas at 4:02 AM on August 14, 2022 [2 favorites]
The stress level seriously depends on the company culture and the... user competence level, and a lot of luck. There's no way to predict it without actually visiting the job and observe their work.
If it's a call-center or grunt- level (i.e. tier 1) then you're under the gun most of the time. Call Center often will measure the time you spent on the phone per customer and if it goes over a certain threshold you get a call or visit from the supervisor, as many have mentioned. (buzzword: KPI, key performance indicator) And grunt level often means you have to walk over to the user's cube and see what had they done to their equipment, and there are plenty of tales to tell. Reddit has a subreddit dedicated to both topics (/r/talesfromcallcenters and /r/talesfromtechsupport) with some interesting stories to tell. Then it's a matter of following the policy / script given. There were stories about users who doesn't like her equipment so she intentionally put a heater on it then demand a more expensive laptop (she didn't need one) when it broke, or the caller who believes she'd get better service by speaking to tier 2 and refuse to even tell you what's wrong, not even enough info to handover to the supervisor or tier 2... But most users are nice and just want their problem(s) resolved.
On the other hand, if you luck out and work at a calmer place, maybe a law office where the users are at least somewhat competent with their equipment, and don't abuse them, and you have spares available that can be deployed at a moment's notice, in case Murphy's Law strikes, then it can be a pretty calm existence where you spend most of the day, doing inventory, updating documentation, fix file permissions, and things like that. But when it's an emergency, it's a real emergency.
posted by kschang at 6:03 AM on August 14, 2022 [1 favorite]
If it's a call-center or grunt- level (i.e. tier 1) then you're under the gun most of the time. Call Center often will measure the time you spent on the phone per customer and if it goes over a certain threshold you get a call or visit from the supervisor, as many have mentioned. (buzzword: KPI, key performance indicator) And grunt level often means you have to walk over to the user's cube and see what had they done to their equipment, and there are plenty of tales to tell. Reddit has a subreddit dedicated to both topics (/r/talesfromcallcenters and /r/talesfromtechsupport) with some interesting stories to tell. Then it's a matter of following the policy / script given. There were stories about users who doesn't like her equipment so she intentionally put a heater on it then demand a more expensive laptop (she didn't need one) when it broke, or the caller who believes she'd get better service by speaking to tier 2 and refuse to even tell you what's wrong, not even enough info to handover to the supervisor or tier 2... But most users are nice and just want their problem(s) resolved.
On the other hand, if you luck out and work at a calmer place, maybe a law office where the users are at least somewhat competent with their equipment, and don't abuse them, and you have spares available that can be deployed at a moment's notice, in case Murphy's Law strikes, then it can be a pretty calm existence where you spend most of the day, doing inventory, updating documentation, fix file permissions, and things like that. But when it's an emergency, it's a real emergency.
posted by kschang at 6:03 AM on August 14, 2022 [1 favorite]
Response by poster: Thanks for all the answers so far, they’ve been helpful, and added to my ‘pros’ and ‘cons’ columns in interesting ways.
The discussion of the customer service aspect makes me feel more confident I’d be good at and hopefully enjoy the work - I used to do academic skills tutoring and the dynamic sounds similar, and I found doing that thing of helping people in a distressed and confused place get through a problem satisfying in itself. So that’s a big pro for me.
The discussion of the ‘crunch mode’ aspect I guess semi-confirms my fears. That it depends on the culture of an organisation or team makes sense, although it’s encouraging to hear it works in more than one way and not everywhere is using number of tickets cleared as the one true kpi. I’d feared that might be universal. So I guess that’s part pro, part con.
That it’s realistically a potential ‘foot in the door’ for other things, and to learn the lay of the land for what’s involved in other roles is interesting and encouraging. I hadn’t thought of IT support roles in that way before, but it makes sense now you mention it. I am a bit of a Jack of all trades just as a fundamental feature of my personality, so that aspect of dipping into a variety of things seems like a good fit. So that’s an unexpected pro.
Re: the question about what else was in my preference list, at the top I nominated project management, for the reason that it seemed (to me) a logical step from skills I’ve been actively developing in my current work over the last few years: managing teams of people and projects of varying complexity, but in a teaching/ teaching admin context. I think second was UI/UX, again based on the logic it extends on existing skills - I’ve got a good understanding of people, communication, and ways interaction works, I have background in interactive art and communication theory, and I’ve got experience working with my current workplace’s eLearning team developing templates / structures for online learning. IT support was third based on things mentioned above. The common thread between the three being I feel like my strengths lie in wrangling situations where human behaviour and technology meet.
posted by threecheesetrees at 8:03 AM on August 14, 2022
The discussion of the customer service aspect makes me feel more confident I’d be good at and hopefully enjoy the work - I used to do academic skills tutoring and the dynamic sounds similar, and I found doing that thing of helping people in a distressed and confused place get through a problem satisfying in itself. So that’s a big pro for me.
The discussion of the ‘crunch mode’ aspect I guess semi-confirms my fears. That it depends on the culture of an organisation or team makes sense, although it’s encouraging to hear it works in more than one way and not everywhere is using number of tickets cleared as the one true kpi. I’d feared that might be universal. So I guess that’s part pro, part con.
That it’s realistically a potential ‘foot in the door’ for other things, and to learn the lay of the land for what’s involved in other roles is interesting and encouraging. I hadn’t thought of IT support roles in that way before, but it makes sense now you mention it. I am a bit of a Jack of all trades just as a fundamental feature of my personality, so that aspect of dipping into a variety of things seems like a good fit. So that’s an unexpected pro.
Re: the question about what else was in my preference list, at the top I nominated project management, for the reason that it seemed (to me) a logical step from skills I’ve been actively developing in my current work over the last few years: managing teams of people and projects of varying complexity, but in a teaching/ teaching admin context. I think second was UI/UX, again based on the logic it extends on existing skills - I’ve got a good understanding of people, communication, and ways interaction works, I have background in interactive art and communication theory, and I’ve got experience working with my current workplace’s eLearning team developing templates / structures for online learning. IT support was third based on things mentioned above. The common thread between the three being I feel like my strengths lie in wrangling situations where human behaviour and technology meet.
posted by threecheesetrees at 8:03 AM on August 14, 2022
Depends on your aptitude and interest in tech, then. Maybe to take a class or two on SCRUM and Agile, and see how you like project management?
posted by kschang at 9:04 AM on August 14, 2022 [1 favorite]
posted by kschang at 9:04 AM on August 14, 2022 [1 favorite]
When I managed technical support at a university, we worked closely with the Blackboard support staff, who assisted faculty with online course development. With your background, Online Course Developer\Designer, Instructional Designer/ Technologist are some job titles. You can probably get free training for Google classroom. I don't know what the current platforms are are these days. I did some backend tasks, like most specialized large platforms, it's not very intuitive, usually kind of rigid, but learnable.
Data Analyst is a growing need. If they'll pay for training, it might be useful to get certified on Windows, Office, and then look at databases and Project. The pay is better than Tech Support jobs, better status and lots of options.
posted by theora55 at 9:14 AM on August 14, 2022 [2 favorites]
Data Analyst is a growing need. If they'll pay for training, it might be useful to get certified on Windows, Office, and then look at databases and Project. The pay is better than Tech Support jobs, better status and lots of options.
posted by theora55 at 9:14 AM on August 14, 2022 [2 favorites]
I've read horror stories about companies where there was only one IT person, and they were on call 24 hours a day, and never allowed to take leave.
Yeah, I should mention something about this: don’t.
If it comes to this, walk. Don’t let anyone tell you you shouldn’t or stop you, not for pride or the team or money. Carrying a pager for a few days in a relatively stable, technically competent workplace? Fine, that’s not great but it’s doable.
24/7 for weeks on end? Absolutely not. That destroys people.
posted by mhoye at 10:49 AM on August 14, 2022 [2 favorites]
Yeah, I should mention something about this: don’t.
If it comes to this, walk. Don’t let anyone tell you you shouldn’t or stop you, not for pride or the team or money. Carrying a pager for a few days in a relatively stable, technically competent workplace? Fine, that’s not great but it’s doable.
24/7 for weeks on end? Absolutely not. That destroys people.
posted by mhoye at 10:49 AM on August 14, 2022 [2 favorites]
I manage the support operation for a company that works with large enterprise applications that we specialise in. The support people we have are at the high end of the spectrum of pay and responsibility: most are comping in with either a few years of application specific experience or with at least having worked with the key elements that underpin enterprise software. Here are some quick points on what I believe makes good support people in this context:
1. They are people who are happy to leap in to take responsibility for solving a problem - that kind of person who says "How can I help?" and then listens to the reply. They tend to take the problem off the plate of those who are bringing it along, advocate for the people who are raising the issue, reach out to experts as necessary, work out the root cause, solve it and explain clearly what they have done. As such, there is quite a lot that good teachers and good support people have in common; if you have taught - and enjoyed it - then that will be useful for the role.
2. Software support is often spoken about in terms of levels - the work we do mainly involves 2nd or 3rd line support - which means that it concerns issues which are getting raised by people who manage and own systems - rather than end users. As such, there are few easy answers - and the really important skill is often no so much what you know as about how you handle what you don't know.
3. For reasons 1 and 2, the best support people for us are those who are passionate learners: they will be people who are always reading training material, specifications, release notes etc. They will also be keen to improve their handling of difficult people: as others have said, support people are in the firing line for those who are under pressure from their own job and who are getting driven mad by whatever glitch our system has put in their way. I would echo those who say that support provides one of the quickest and most effective learning paths through the world of IT, for those who are willing to follow it.
4. We get people who are destined to make the transition from support into consultancy - and sometimes we get consultants who are looking to move into support. Often people work on a bit of both to broaden their experience. Consider what your possible development path might be.
5. If you have a choice of choosing an organisation to work for, you are often better supporting that is expensive for an organisation to deploy and when working for people who sell and develop or configure for that expensive thing.
6. In terms of specifics to learn: I would echo kschang's mention of Agile and of understanding project management generally. And I would say that knowing your way around SQL to the extend where you could write some exploratory queries, would be useful.
7. Most IT systems - and particular configurations of them even more so - are pretty poorly documented. So, again as mentioned, you can get into a role where you are finding and filling in the gaps by creating this. What you create can vary: demonstration videos or PPT decks, PDFs, etc.
posted by rongorongo at 11:28 AM on August 14, 2022 [3 favorites]
1. They are people who are happy to leap in to take responsibility for solving a problem - that kind of person who says "How can I help?" and then listens to the reply. They tend to take the problem off the plate of those who are bringing it along, advocate for the people who are raising the issue, reach out to experts as necessary, work out the root cause, solve it and explain clearly what they have done. As such, there is quite a lot that good teachers and good support people have in common; if you have taught - and enjoyed it - then that will be useful for the role.
2. Software support is often spoken about in terms of levels - the work we do mainly involves 2nd or 3rd line support - which means that it concerns issues which are getting raised by people who manage and own systems - rather than end users. As such, there are few easy answers - and the really important skill is often no so much what you know as about how you handle what you don't know.
3. For reasons 1 and 2, the best support people for us are those who are passionate learners: they will be people who are always reading training material, specifications, release notes etc. They will also be keen to improve their handling of difficult people: as others have said, support people are in the firing line for those who are under pressure from their own job and who are getting driven mad by whatever glitch our system has put in their way. I would echo those who say that support provides one of the quickest and most effective learning paths through the world of IT, for those who are willing to follow it.
4. We get people who are destined to make the transition from support into consultancy - and sometimes we get consultants who are looking to move into support. Often people work on a bit of both to broaden their experience. Consider what your possible development path might be.
5. If you have a choice of choosing an organisation to work for, you are often better supporting that is expensive for an organisation to deploy and when working for people who sell and develop or configure for that expensive thing.
6. In terms of specifics to learn: I would echo kschang's mention of Agile and of understanding project management generally. And I would say that knowing your way around SQL to the extend where you could write some exploratory queries, would be useful.
7. Most IT systems - and particular configurations of them even more so - are pretty poorly documented. So, again as mentioned, you can get into a role where you are finding and filling in the gaps by creating this. What you create can vary: demonstration videos or PPT decks, PDFs, etc.
posted by rongorongo at 11:28 AM on August 14, 2022 [3 favorites]
Enterprise IT support typically has multiple tiers. Depending on the scale of the service, it may combine some of what I describe below, or even omit it entirely.
At Tier 1, you are basically taking calls and answering phone calls. Aka "helpdesk." You are effectively the complaints department, and can expect an unusual amount of angry callers daily. You probably have a script to follow for common issues, like resetting passwords. Depending on the scale, you may have a call center style job where managers obsess over metrics like call duration on an employee basis. This work rarely follows you home.
Tier 2 is a bit more nebulous, but basically an escalation target. They're usually either a senior helpdesk or junior IT staff in another role. When the helpdesk script doesn't work, they get the call. They usually specialize in one area of the system, and usually have additional administrative powers to investigate and repair. They generally have a more leisurely pacing, as the problems that land on their plate are often unique. They may be assigned other duties in addition, like software upgrades, helpdesk script updates, or automation projects. When I was in this role, we had a pager but I did not take it out of the building.
Tier 3 is basically where I work. Many different role names can apply at this tier: Sysadmin, Site Reliability Engineer, Operations Engineer, etc. Our primary job is to detect and repair issues before the call comes in. In order to do that, we need to understand the system and product, not only in how it works, but how it fails. Practicing decompositional analysis -- dividing the system into components and ruling them out as causal -- is a key skill when a ticket lands on your desk. At small scales, you just write and rely on automated probes. At larger scales, you need to apply an additional layer of statistical rigor to detect partial outages, and analyze canary deployments of software changes. This is definitely a place where on-call is a thing. Standard practice is usually 1 week 24/7, rotating amongst the team. Larger services may staff a follow the sun model with 3 offices spaced around the world splitting oncall into 3 shifts of 8 hours every day.
At some places Tier 3 is also the team / person who wrote the system. At others, they effectively sit at Tier 4, possibly in an unofficial way. When SRE believes the problem is a bug in the software, they may need to escalate to the software developers to prioritize a bug fix. Developers may or may not be on call, and definitely have other projects to deliver features, etc. They're also more likely to interact with project managers, designers, and product managers.
posted by pwnguin at 11:44 AM on August 14, 2022 [3 favorites]
At Tier 1, you are basically taking calls and answering phone calls. Aka "helpdesk." You are effectively the complaints department, and can expect an unusual amount of angry callers daily. You probably have a script to follow for common issues, like resetting passwords. Depending on the scale, you may have a call center style job where managers obsess over metrics like call duration on an employee basis. This work rarely follows you home.
Tier 2 is a bit more nebulous, but basically an escalation target. They're usually either a senior helpdesk or junior IT staff in another role. When the helpdesk script doesn't work, they get the call. They usually specialize in one area of the system, and usually have additional administrative powers to investigate and repair. They generally have a more leisurely pacing, as the problems that land on their plate are often unique. They may be assigned other duties in addition, like software upgrades, helpdesk script updates, or automation projects. When I was in this role, we had a pager but I did not take it out of the building.
Tier 3 is basically where I work. Many different role names can apply at this tier: Sysadmin, Site Reliability Engineer, Operations Engineer, etc. Our primary job is to detect and repair issues before the call comes in. In order to do that, we need to understand the system and product, not only in how it works, but how it fails. Practicing decompositional analysis -- dividing the system into components and ruling them out as causal -- is a key skill when a ticket lands on your desk. At small scales, you just write and rely on automated probes. At larger scales, you need to apply an additional layer of statistical rigor to detect partial outages, and analyze canary deployments of software changes. This is definitely a place where on-call is a thing. Standard practice is usually 1 week 24/7, rotating amongst the team. Larger services may staff a follow the sun model with 3 offices spaced around the world splitting oncall into 3 shifts of 8 hours every day.
At some places Tier 3 is also the team / person who wrote the system. At others, they effectively sit at Tier 4, possibly in an unofficial way. When SRE believes the problem is a bug in the software, they may need to escalate to the software developers to prioritize a bug fix. Developers may or may not be on call, and definitely have other projects to deliver features, etc. They're also more likely to interact with project managers, designers, and product managers.
posted by pwnguin at 11:44 AM on August 14, 2022 [3 favorites]
Response by poster: Thank you again for painting an even clearer picture of the structure of the work environment and the various roles that fall under the 'IT support' banner, and for your suggestions.
I think I might actually turn down the training I've been offered: a micro-credential spun off from this Cert III course (in Australian higher ed. parlance, Cert III is equivalent to the first semester-ish of a bachelor), and look into something more fully-fledged. I feel like I'd be taking it more seriously and giving myself a better start that way, and the full Cert III and Cert IV courses aren't free but they are government subsidized where I am, and would allow more choice in terms of focus of study/training provider.
Rongorongo's suggestion of finding a role creating documentation jumped out at me as something that feels like a pretty natural fit for me, as I kind of already do that – creating resources and walk-through videos for using the systems used at my current workplace to supplement the official documentation. Any suggestions on how to get into a role like that?
posted by threecheesetrees at 8:54 PM on August 14, 2022
I think I might actually turn down the training I've been offered: a micro-credential spun off from this Cert III course (in Australian higher ed. parlance, Cert III is equivalent to the first semester-ish of a bachelor), and look into something more fully-fledged. I feel like I'd be taking it more seriously and giving myself a better start that way, and the full Cert III and Cert IV courses aren't free but they are government subsidized where I am, and would allow more choice in terms of focus of study/training provider.
Rongorongo's suggestion of finding a role creating documentation jumped out at me as something that feels like a pretty natural fit for me, as I kind of already do that – creating resources and walk-through videos for using the systems used at my current workplace to supplement the official documentation. Any suggestions on how to get into a role like that?
posted by threecheesetrees at 8:54 PM on August 14, 2022
Rongorongo's suggestion of finding a role creating documentation jumped out at me as something that feels like a pretty natural fit for me, as I kind of already do that – creating resources and walk-through videos for using the systems used at my current workplace to supplement the official documentation. Any suggestions on how to get into a role like that?
This is called technical writing, and that's what I do for a living. How to get into tech writing is a common question over on r/technicalwriting on Reddit, and also comes up on the Write the Docs Slack.
The general answer is to create a portfolio of work that you can show, and start applying for technical writer / technical communicator roles. It can be difficult to get that first foot in the door, but it's doable with some persistence.
I'm not sure how it is in Australia, but here in the US every tech writing job offer I've gotten in the past 6 or 7 years, including my current job, has come through LinkedIn. So it would be a good idea to have a LinkedIn profile that you've spent time on and that makes it clear what kind of work you want to be doing. For example, if you're looking for tech writing roles, emphasize the fact that you've done that kind of work at previous jobs.
posted by ralan at 4:52 AM on August 15, 2022 [1 favorite]
This is called technical writing, and that's what I do for a living. How to get into tech writing is a common question over on r/technicalwriting on Reddit, and also comes up on the Write the Docs Slack.
The general answer is to create a portfolio of work that you can show, and start applying for technical writer / technical communicator roles. It can be difficult to get that first foot in the door, but it's doable with some persistence.
I'm not sure how it is in Australia, but here in the US every tech writing job offer I've gotten in the past 6 or 7 years, including my current job, has come through LinkedIn. So it would be a good idea to have a LinkedIn profile that you've spent time on and that makes it clear what kind of work you want to be doing. For example, if you're looking for tech writing roles, emphasize the fact that you've done that kind of work at previous jobs.
posted by ralan at 4:52 AM on August 15, 2022 [1 favorite]
This is called technical writing, and that's what I do for a living. How to get into tech writing is a common question over on r/technicalwriting on Reddit, and also comes up on the Write the Docs Slack.
I also remember some good AskMe questions (ex1, ex2) on how to get into being a technical writer.
Companies in the IT realm hire technical writers when they have a suitably large audience for a piece of piece of documentation. If writing documentation is the real essence of what you want to do - then it would be a great option. There is a whole lot of documentation that does not have a sufficient audience size to merit hiring a writer especially - and that is the type of category which IT Support people can sometimes end up getting asked to create - so don't overlook that avenue.
What qualifies as "Documentation" within IT, has changed quite a lot too. Twenty years ago it was overwhelmingly about printed books and manuals, web pages or Powerpoint decks delivered to a classroom. These days video consumed online is ever more important: maybe a "How to" done on Youtube or a recorded presentation done on Teams. So: if you are going to specialise in that particular area - have a think about what forms interest you most and what forms that jobs market are talking about.
posted by rongorongo at 6:40 AM on August 15, 2022 [1 favorite]
I also remember some good AskMe questions (ex1, ex2) on how to get into being a technical writer.
Companies in the IT realm hire technical writers when they have a suitably large audience for a piece of piece of documentation. If writing documentation is the real essence of what you want to do - then it would be a great option. There is a whole lot of documentation that does not have a sufficient audience size to merit hiring a writer especially - and that is the type of category which IT Support people can sometimes end up getting asked to create - so don't overlook that avenue.
What qualifies as "Documentation" within IT, has changed quite a lot too. Twenty years ago it was overwhelmingly about printed books and manuals, web pages or Powerpoint decks delivered to a classroom. These days video consumed online is ever more important: maybe a "How to" done on Youtube or a recorded presentation done on Teams. So: if you are going to specialise in that particular area - have a think about what forms interest you most and what forms that jobs market are talking about.
posted by rongorongo at 6:40 AM on August 15, 2022 [1 favorite]
There is only ONE good reason for going into IT: you want, really truly deeply want, to help ignorant people with the same issues, over and over again.
(I mean "ignorant" in the literal non-judgemental sense, not the pejorative sense; as mhoye said above, most of the people you'll support don't and don't want to understand the computers their jobs rely on.)
You'll need every ounce of that personal conviction, passion, and especially compassion to keep from getting burned out on helping these people. And don't expect to get any gratitude from them - it does happen, but only rarely.
All that said, my IT career is 30 years long and only occasionally do I dream of leaving it! No lasting regrets.
posted by Greg_Ace at 4:57 PM on August 15, 2022 [1 favorite]
(I mean "ignorant" in the literal non-judgemental sense, not the pejorative sense; as mhoye said above, most of the people you'll support don't and don't want to understand the computers their jobs rely on.)
You'll need every ounce of that personal conviction, passion, and especially compassion to keep from getting burned out on helping these people. And don't expect to get any gratitude from them - it does happen, but only rarely.
All that said, my IT career is 30 years long and only occasionally do I dream of leaving it! No lasting regrets.
posted by Greg_Ace at 4:57 PM on August 15, 2022 [1 favorite]
This thread is closed to new comments.
Frustrations: The network managers and developers tend to have low respect for Tech Support. This can make it harder to resolve problems.
It's sexist and ageist.
In some places, calls are timed and managed so that it feels like factory work, scheduled so that there are always calls in queue, and always a push to get off this call and get the next one.
posted by theora55 at 6:56 PM on August 13, 2022 [7 favorites]