Organization Experience
Over the three years that I've spent working in tech support, changes occurred that have affected my responsibilities and work environment, as well as the expectations in my performance.
When I first started out, my responsibilities simply consisted of troubleshooting equipment issues. It would mainly be done over the phone, but if the issue was urgent, I'd go out into the field to try to resolve it. When resolving issues over the phone, there was a procedure that everyone had to follow. First, you'd refer to a database that was managed by the organization. If the solution couldn't be found there, you'd ask a team lead, and then if they didn't know the answer, a manager would be asked. If I had to go out in the field and couldn't fix it, I'd radio a technician and then they would handle the issue. There were night shifts too. During these shifts, a group of people would go out checking the equipment. This was to stay on top of any issues before they caused trouble. The organization also had a second tech support team. They took care of any issues that weren't related to the equipment, such as online services and account questions. This division of labor allowed for each support group to have a more specialized level of knowledge. With this specialization came a regularity and specificity of the issues we faced, reducing the transaction costs of finding solutions.
Documentation was very important. Whenever an issue came in, was resolved, or there was any type of interaction related to an issue, it had to be documented. To ensure we were doing quality work, these tickets would be reviewed, and there would be survey's sent out whenever an issue was resolved. These surveys were used to evaluate our performance. Large numbers of issues would be processed, so every ticket and survey wouldn't be reviewed, but Individual ones would more or less be randomly selected. This monitoring would be performed by team leads, and corrective feedback would be given if mistakes were made. This helped ensure people were following set procedures.
After my second year working there, some changes occurred. Resources became tight, leading to fewer technicians being employed. With fewer techs available, they weren't able to help out with as many issues. We had to become more resourceful as a result. This included trying to fix an issue, even if you didn't know what you were doing. In order to manage the reduction in workforce, a buffer was created to avoid sending out technicians. First a student would go out to inspect the issue, if they couldn't fix it, then they would assign it to a tech.
Shifts in responsibilities continued throughout the year, and eventually the two tech support teams merged. Merging the two groups involved retraining both teams so they would understand what the other support group managed before.The job remained very much the same, there was just a wider variety of issues to address. Metrics became more important, and goals were set for the organization as a whole to ensure quality service and value was being delivered. This restructuring expanded the area of issues each person could resolve on their own, and made it easier for people to find help. While reducing the cost of transferring information, it also created more work for everyone.
The reorganizing of the organization involved more than just structural changes. There were also cultural and symbolic components. With the merging of the two groups, there was a transition period where the acceptance of new hierarchies and responsibilities was made. There were also more social events to foster collegiality among peers and higher ups. The symbolic reorganization occurred on a higher level and was more so for branding. The organization changed their name and wanted to make clear the services they offered.
When I first started out, my responsibilities simply consisted of troubleshooting equipment issues. It would mainly be done over the phone, but if the issue was urgent, I'd go out into the field to try to resolve it. When resolving issues over the phone, there was a procedure that everyone had to follow. First, you'd refer to a database that was managed by the organization. If the solution couldn't be found there, you'd ask a team lead, and then if they didn't know the answer, a manager would be asked. If I had to go out in the field and couldn't fix it, I'd radio a technician and then they would handle the issue. There were night shifts too. During these shifts, a group of people would go out checking the equipment. This was to stay on top of any issues before they caused trouble. The organization also had a second tech support team. They took care of any issues that weren't related to the equipment, such as online services and account questions. This division of labor allowed for each support group to have a more specialized level of knowledge. With this specialization came a regularity and specificity of the issues we faced, reducing the transaction costs of finding solutions.
Documentation was very important. Whenever an issue came in, was resolved, or there was any type of interaction related to an issue, it had to be documented. To ensure we were doing quality work, these tickets would be reviewed, and there would be survey's sent out whenever an issue was resolved. These surveys were used to evaluate our performance. Large numbers of issues would be processed, so every ticket and survey wouldn't be reviewed, but Individual ones would more or less be randomly selected. This monitoring would be performed by team leads, and corrective feedback would be given if mistakes were made. This helped ensure people were following set procedures.
After my second year working there, some changes occurred. Resources became tight, leading to fewer technicians being employed. With fewer techs available, they weren't able to help out with as many issues. We had to become more resourceful as a result. This included trying to fix an issue, even if you didn't know what you were doing. In order to manage the reduction in workforce, a buffer was created to avoid sending out technicians. First a student would go out to inspect the issue, if they couldn't fix it, then they would assign it to a tech.
Shifts in responsibilities continued throughout the year, and eventually the two tech support teams merged. Merging the two groups involved retraining both teams so they would understand what the other support group managed before.The job remained very much the same, there was just a wider variety of issues to address. Metrics became more important, and goals were set for the organization as a whole to ensure quality service and value was being delivered. This restructuring expanded the area of issues each person could resolve on their own, and made it easier for people to find help. While reducing the cost of transferring information, it also created more work for everyone.
The reorganizing of the organization involved more than just structural changes. There were also cultural and symbolic components. With the merging of the two groups, there was a transition period where the acceptance of new hierarchies and responsibilities was made. There were also more social events to foster collegiality among peers and higher ups. The symbolic reorganization occurred on a higher level and was more so for branding. The organization changed their name and wanted to make clear the services they offered.
Working there - you never said where you worked. Even if you were reluctant to name the company you might have given some general sense of the nature of its business. You also were unclear whether you work there during the school year or only in the summers.
ReplyDeleteIn the paragraph where you talked about workforce reduction and adjustments that were made, you distinguished between a student and a tech. The distinction clearly is meaningful to you. But to me, you are a student and you had a job as a tech. So I was confused by that. It might be good to distinguish between one or the other.
When I worked in the campus IT organization, my edtech unit did consulting with faculty clients, which included trouble shooting on software. There was a separate help desk that did trouble shooting for the entire campus, and I believe included both hardware and software consulting. A big deal issue was how queries got routed. The engineers inside the organization really only wanted to interact with other techies around campus, and then only if the request was important enough. My guess is that your job had something of a similar issue with it, though sales people might want to route higher quality service to more important customers. Did anything like that happen for you?
You described the second support group reasonably well, but I didn't get a sense of how when they were separate people would be assigned to one or the other. Was it a skill thing, more a matter of inclination, or wherever there were vacancies? I also didn't get a sense of whether you are all in the same physical place or not. Can you do tech support from your place of residence or not?
Finally, though not really part of the prompt, I'm curious whether this work ties into being an Econ major at all or if they are two entirely different set of skills. And if the latter, how do you stay current with that and pursue school at the same time?
The student vs tech distinction is that most of the techs were full time employees, whereas most of the part timers were students. The organization would take care of tech issues, such as troubleshooting computer issues or recovering account information.
DeleteYes, routing issues to the proper people and escalating them to higher ups only when necessary was very important. You pretty much had to make sure you exhausted all available resources available to you before passing it on to someone with more authority/knowledge.
I'm really not sure what the two groups considered when hiring people, or if they collaborated in making those decisions. I imagine it was simply based on vacancies, at least as far as the part time positions go. While there were many aspects of the job that you could do remotely, it wasn't an option to do so.
I wouldn't say this is work a person that a person would pursue if they only wanted to do things that were explicitly econ. On a higher level, the organization roles and responsibilities are well defined, and there is a bit of history to it. Given this, it might lend itself nicely to an economic analysis. The job doesn't require a very specialized, or at least deep understanding of anything in particular. The most important skill for this job would be finding the answer to an issue in some documentation, and then either following the instructions or stepping someone through them.