Support department: waiting vs reality
Good day. I would like to tell a little story that happened to me not so long ago and is associated both with career expectations and with an erroneous perception of what is happening in reality. How an employer can be misleading or unknowingly harm the motivation of the team.
Arriving in a provincial city from Moscow, I was going to get a job as the head of the IT department in some company. Having passed advanced training in Moscow and all the stages of work from the first line to the third, realizing that I like management and management of people / processes and I can do it, I began to look for a vacancy.
Details under the cut.
Specially not distracted by the transformer vacancies, when the company needs “both a specialist, and a reaper, and a igretsa” (this is when a person should write both the soldering board and the 1C configuration) I waited patiently for a good offer. After 2 months, the deputy head of the department came to me, with a proposal that was hard to disagree with. The direction has just appeared, a federal-scale company creating a support and development department in the region, the plans were ambitious and completely met my expectations. It was possible to build a team and processes from scratch, optimize and integrate them into existing processes. All called the post with the functions of "coordinator \ head of technical support." Well, I was ready to fight.
What I wanted:Since I had to maintain the purchased information system, and I used to deal more with the hardware infrastructure, I decided to get up to date gradually from the side that was most obvious to me - I asked for the rules of the processes automated by the system and its documentation. And I ran into the first surprise - there was no documentation from the system purchased for the “money”. There were slides sketched by the company on the knee, how certain roles are involved in the process and that's it. The company had another 4 months of support under the contract, when they could be contacted with questions about the work of the system. There was no internal project for the implementation of the system, the deadlines were set by an agreement and an excel document, which indicated the deadlines for the implementation of certain improvements. Yes, after my hiring, the system was added for another 5 months.
What happened: With a sin in half, described several processes in the form of schemes Visio. Partially described modules of the system. Due to the failure of the deadlines, communication with the developers of the purchased system has become even worse. As far as I understood, the obligatory documentation did not stipulate the purchase.
Conclusion: An undocumented unfinished system is poorly described without the help of developers. Try to streamline the communication process.
What I wanted: Support on the first line was supposed to collect a certain pool of questions from users, it was assumed that managers already have this pool, at least partially. But after negotiations with the head of the sales department, it became clear that there was no pool and the process would look like this: the user calls, if it is connected with the technical part, we help, if with the business part, then we call back. Since the business part of the answers was not at all, the first users should not have been very lucky. Again, during the conversation, I realized that business doesn’t really value new users and is ready to take these risks.
To clarify, with such sources, the picture seemed rather vague, but I took it as a challenge.
What happened:Created a document to cover the initial volume of business consultations. The procedure for working with the business failed to regulate. The new question "not from the list" business could forget to answer. Had to re-request, keeping control. Based on docuwiki, a knowledge base has been created with a description of issues, system architecture, basic second-line support actions and administrators. It was not possible to describe the setting up of creating a new product in the system, since it was created in a semi-programmable way and it was necessary to describe together with the programmers.
Conclusion: Creating a knowledge base by sacrificing customer loyalty is the wrong step. If a business does this, then additional support is placed on support in the form of excuses for flaws and restraining additional negative customers.
What I wanted: For the selection of employees to my team I approached methodically: I chose a list of competencies and composed questions for a telephone interview on these competencies. At first, all the questions had the same weight, and after a couple of interviews, I realized that all candidates are equally suitable for the vacancy and at such a rate you can hire people for a long time. All competencies were given weight and the process went more fun.
Competency table of the first line:
This template was sent for approval with management, but the “apply-not apply” response was not returned.
I took the first person on the recommendation of an old colleague without a template (he worked for a week). Next took the chef. The remaining three (girls) were recruited partly with my participation, but without asking for my recommendations and without being interested in opinion. Admission to material motivation and budgets I have not received.
What happened: A cheerful, but not fully compliant department was recruited, where employees do an excellent job on the first line, but for a deeper dive into the system, a properly crafted learning process and knowledge transfer are required. In my presence, people with a salary above the market average lost their intangible motivation before the eyes due to an incorrectly set work process.
Conclusion: prepare for the new motivated employee the amount of work. Otherwise, it is bad for loyalty to the employer and to the system. Understand the process of staff motivation - both material and non-material.
What I wanted: After the launch of the system, we started to face the first difficulties: the old interface looked awful and worked against all concepts user-friendly. The main flow of calls went on dissatisfaction with the interface, and not the business process. Users simply could not make a request. Before the newly recruited development team, the main mistakes were immediately communicated, but here we faced a second problem: there was no communication not only with those who supported the system from the outside, but there was no prioritization to correct the system - all the forces were put to writing new functions and products, it was impossible to allocate a person for patching elementary errors that would reduce the number of calls in half.
What happened:After another indication of the problems to management, it nevertheless gave permission to make corrections and the flow of calls decreased threefold.
Conclusion: streamline the process of prioritizing tasks by discussing how to interact with the development team.
Facing each of the above tasks, each time I came to the management with proposals to optimize the processes and attempt to coordinate my vision with the company's vision, but always ran into either the manager’s employment (system problem) or received the answer “so far” and “we don’t want excessive formalization ". I also knew that the expansion of the department to 5 people was planned and I saw that it was necessary to understand how the support process and resources would be managed. I had already begun to suspect that the authorities had changed plans for me because of my constant attempts to introduce changes. I was no longer called the coordinator or the boss; I did not participate in the meetings related to the development of the system.
After that, I decided to prepare a strategy and understand whether I was doing that at all. Because the chief did not communicate with me in terms of strategy at all. The strategy was directed immediately to the higher-ranking person in IT in Moscow and, for me, the picture of my work has changed. Then the strategy was sent from Moscow down to my direct superiors and I got into confrontation with the local boss.
Conclusion: Analyze the division strategy. Identify short and long term plans. Discuss the vision with the guide.
After the above episode, the direct boss almost stopped talking to me. And I started thinking about quitting. Initially, I saw an interesting project that, after overcoming certain difficulties with the right interaction of all participants in the process, could be successfully completed, having received a strong, motivated support department with correct KPIs and with clear output indicators that were clear business. Now, I saw that the department was falling into a routine without really developing. Two tasks became priorities: answering calls and describing bugs (not completions) of the system through gitlab, which were corrected by the developers.
A separate story is the process of “testing,” as the manager called him, who was also asked to perform by us. No one had an understanding of these procedures, as well as a separate tester. Functional testing of the “black box” without any performance indicators by the whole team before the release. No other methods were used. The recruited staff could not effectively participate in the testing due to the lack of a background in the field of development, and due to the lack of a learning process. Dates of releases constantly faylilis or releases rolled out without testing.
Conclusion: the department can not effectively deal with two large processes in parallel. There will be two processes going on somehow.
The confrontation continued. The head managed to zafilit all elements of management, which I considered important:
Also magical items such as “loyalty to the company in the form of coming to work earlier and leaving later” were voiced.
Finally, having lost motivation, I invited the head to talk about my future position in the company and the decision to leave it, where I was told that the department in in its current form, everyone is happy and the development of individual elements is not planned. In the end, I left the company, having gained practical experience in trying to implement my vision of the work of the support department.
What happened: experience, experience and experience again.
Conclusion: What mistakes did I fix for myself:
I would also like to hear from colleagues your introduction stories and nuances to which, due to inexperience, I did not pay attention.
Arriving in a provincial city from Moscow, I was going to get a job as the head of the IT department in some company. Having passed advanced training in Moscow and all the stages of work from the first line to the third, realizing that I like management and management of people / processes and I can do it, I began to look for a vacancy.
Details under the cut.
Specially not distracted by the transformer vacancies, when the company needs “both a specialist, and a reaper, and a igretsa” (this is when a person should write both the soldering board and the 1C configuration) I waited patiently for a good offer. After 2 months, the deputy head of the department came to me, with a proposal that was hard to disagree with. The direction has just appeared, a federal-scale company creating a support and development department in the region, the plans were ambitious and completely met my expectations. It was possible to build a team and processes from scratch, optimize and integrate them into existing processes. All called the post with the functions of "coordinator \ head of technical support." Well, I was ready to fight.
Initial goals:
- Support on the first and second line.
- Creating a knowledge base
- Creating user documentation
- Understand the business process for “business consulting”
- Prepare regulations for departmental interactions as part of the ITIL Service Desk methodology (I planned to take from there only the process of passing requests and incidents + writing SLAs, because I know that no one will implement a fully formalized process, and it will not work)
- Hire support staff.
Documentation creation
What I wanted:Since I had to maintain the purchased information system, and I used to deal more with the hardware infrastructure, I decided to get up to date gradually from the side that was most obvious to me - I asked for the rules of the processes automated by the system and its documentation. And I ran into the first surprise - there was no documentation from the system purchased for the “money”. There were slides sketched by the company on the knee, how certain roles are involved in the process and that's it. The company had another 4 months of support under the contract, when they could be contacted with questions about the work of the system. There was no internal project for the implementation of the system, the deadlines were set by an agreement and an excel document, which indicated the deadlines for the implementation of certain improvements. Yes, after my hiring, the system was added for another 5 months.
What happened: With a sin in half, described several processes in the form of schemes Visio. Partially described modules of the system. Due to the failure of the deadlines, communication with the developers of the purchased system has become even worse. As far as I understood, the obligatory documentation did not stipulate the purchase.
Conclusion: An undocumented unfinished system is poorly described without the help of developers. Try to streamline the communication process.
Creating a knowledge base
What I wanted: Support on the first line was supposed to collect a certain pool of questions from users, it was assumed that managers already have this pool, at least partially. But after negotiations with the head of the sales department, it became clear that there was no pool and the process would look like this: the user calls, if it is connected with the technical part, we help, if with the business part, then we call back. Since the business part of the answers was not at all, the first users should not have been very lucky. Again, during the conversation, I realized that business doesn’t really value new users and is ready to take these risks.
To clarify, with such sources, the picture seemed rather vague, but I took it as a challenge.
What happened:Created a document to cover the initial volume of business consultations. The procedure for working with the business failed to regulate. The new question "not from the list" business could forget to answer. Had to re-request, keeping control. Based on docuwiki, a knowledge base has been created with a description of issues, system architecture, basic second-line support actions and administrators. It was not possible to describe the setting up of creating a new product in the system, since it was created in a semi-programmable way and it was necessary to describe together with the programmers.
Conclusion: Creating a knowledge base by sacrificing customer loyalty is the wrong step. If a business does this, then additional support is placed on support in the form of excuses for flaws and restraining additional negative customers.
Staff recruitment
What I wanted: For the selection of employees to my team I approached methodically: I chose a list of competencies and composed questions for a telephone interview on these competencies. At first, all the questions had the same weight, and after a couple of interviews, I realized that all candidates are equally suitable for the vacancy and at such a rate you can hire people for a long time. All competencies were given weight and the process went more fun.
Competency table of the first line:
This template was sent for approval with management, but the “apply-not apply” response was not returned.
I took the first person on the recommendation of an old colleague without a template (he worked for a week). Next took the chef. The remaining three (girls) were recruited partly with my participation, but without asking for my recommendations and without being interested in opinion. Admission to material motivation and budgets I have not received.
What happened: A cheerful, but not fully compliant department was recruited, where employees do an excellent job on the first line, but for a deeper dive into the system, a properly crafted learning process and knowledge transfer are required. In my presence, people with a salary above the market average lost their intangible motivation before the eyes due to an incorrectly set work process.
Conclusion: prepare for the new motivated employee the amount of work. Otherwise, it is bad for loyalty to the employer and to the system. Understand the process of staff motivation - both material and non-material.
Work process
What I wanted: After the launch of the system, we started to face the first difficulties: the old interface looked awful and worked against all concepts user-friendly. The main flow of calls went on dissatisfaction with the interface, and not the business process. Users simply could not make a request. Before the newly recruited development team, the main mistakes were immediately communicated, but here we faced a second problem: there was no communication not only with those who supported the system from the outside, but there was no prioritization to correct the system - all the forces were put to writing new functions and products, it was impossible to allocate a person for patching elementary errors that would reduce the number of calls in half.
What happened:After another indication of the problems to management, it nevertheless gave permission to make corrections and the flow of calls decreased threefold.
Conclusion: streamline the process of prioritizing tasks by discussing how to interact with the development team.
Facing each of the above tasks, each time I came to the management with proposals to optimize the processes and attempt to coordinate my vision with the company's vision, but always ran into either the manager’s employment (system problem) or received the answer “so far” and “we don’t want excessive formalization ". I also knew that the expansion of the department to 5 people was planned and I saw that it was necessary to understand how the support process and resources would be managed. I had already begun to suspect that the authorities had changed plans for me because of my constant attempts to introduce changes. I was no longer called the coordinator or the boss; I did not participate in the meetings related to the development of the system.
After that, I decided to prepare a strategy and understand whether I was doing that at all. Because the chief did not communicate with me in terms of strategy at all. The strategy was directed immediately to the higher-ranking person in IT in Moscow and, for me, the picture of my work has changed. Then the strategy was sent from Moscow down to my direct superiors and I got into confrontation with the local boss.
Conclusion: Analyze the division strategy. Identify short and long term plans. Discuss the vision with the guide.
The second part of the "Marlezonsky ballet"
After the above episode, the direct boss almost stopped talking to me. And I started thinking about quitting. Initially, I saw an interesting project that, after overcoming certain difficulties with the right interaction of all participants in the process, could be successfully completed, having received a strong, motivated support department with correct KPIs and with clear output indicators that were clear business. Now, I saw that the department was falling into a routine without really developing. Two tasks became priorities: answering calls and describing bugs (not completions) of the system through gitlab, which were corrected by the developers.
A separate story is the process of “testing,” as the manager called him, who was also asked to perform by us. No one had an understanding of these procedures, as well as a separate tester. Functional testing of the “black box” without any performance indicators by the whole team before the release. No other methods were used. The recruited staff could not effectively participate in the testing due to the lack of a background in the field of development, and due to the lack of a learning process. Dates of releases constantly faylilis or releases rolled out without testing.
Conclusion: the department can not effectively deal with two large processes in parallel. There will be two processes going on somehow.
The confrontation continued. The head managed to zafilit all elements of management, which I considered important:
- strategic vision
- control
- control
- motivation
Also magical items such as “loyalty to the company in the form of coming to work earlier and leaving later” were voiced.
Finally, having lost motivation, I invited the head to talk about my future position in the company and the decision to leave it, where I was told that the department in in its current form, everyone is happy and the development of individual elements is not planned. In the end, I left the company, having gained practical experience in trying to implement my vision of the work of the support department.
What happened: experience, experience and experience again.
Conclusion: What mistakes did I fix for myself:
- In order not to waste time - fix and coordinate plans in advance.
- Clearly define the strategy. If there are omissions - resolve issues immediately
- Decide on a comfortable workflow for yourself. Find a compromise between your material and non-material motivation
- Maybe I spent too much time understanding these things. Much lay on the surface
I would also like to hear from colleagues your introduction stories and nuances to which, due to inexperience, I did not pay attention.