Managing a technical support team
You don't have to be a "techie" in order to be able to manage a technical support team effectively. These guidelines explain how.
- Recognise that output is more important to most people than input. In other words, what matters is not so much how long or how hard the technical support team works, but whether the systems are reliable and functioning well most of the time.
- Most technical support problems have non-technical causes, and therefore non-technical solutions.
- If you have just started in the role of managing a technical support team, undertake a fact-finding exercise, to determine what the technical support experience is for various groups of people in the school -- including the students. I have undertaken this work for schools on several occasions, and the findings often come as a surprise to the technical team.
- Introduce reporting and measurement procedures. How many faults were reported this week? How long did it take, on average, to resolve them? What has been done to reduce the risk of the same fault occurring again? It's crucial to have the right data in order to make informed decisions.
- Insist on the proactive involvement of the senior management team. In the work I've done with schools, a consistent message has come through that a passively supportive attitude, while better than an unsupportive one, is not enough.
- Invite the network manager to your department or curriculum meetings, both to listen to what's important to you and, perhaps either briefly every time or, say, once every 6 weeks, to give a report about the network and any matters of concern.
- If you are the educational technology co-ordinator or manager, work towards having the line management of the technical support team taken out of your hands. The technical infrastructure and support of the school ought to be regarded as a maintenance function, not part of a curriculum area.
- In the meantime, allocate some of your budget for training purposes for the technical support staff, especially if they will be asked to implement or manage a new network system, say.
- Ensure that there are clear guidelines for responsibility in place. The role of the technical support team is to advise, implement and maintain. It is your role to ensure that learning takes place. When new computer facilities are being planned, both parties will need to be fully involved in the discussions from the outset.
- Even if part or all of the technical support is outsourced to a third party, you still need interneal procedures which state who should be called, and at what point. For example, there may be first level support, second level support and so on. And you will still need metrics to determine how good the service is.
This is an updated version of an article published in October 2009.
Further reading
Benchmarking and customer satisfaction




Terry Freedman, Educational ICT Consultant

Reader Comments (7)
I do disagree somewhat with your opening statement. Although you are correct in saying that you don't have to be a techie... I have found it really helps cut down costs. In my experience, I have been able to cut through all of their technospeak to get to the real issue. Many times they will recommend the Mercedes of solutions when a Camry will work just fine.
Finally, it is imperative that teachers become tech literate. I have seen animosity grow and grow because the tech support team has gone over the same issue and taught the user many, many times how to harness the technology only for the same mistake to happen time and time again. If this happened in the classroom with students, I'm sure there would be many parent conferences with the offending party!
Thanks for your insights!
I also sort of disagree with your opening statement but you make some valid points.
There are far too many technically illiterate middle managers managing technical support teams and this really needs to stop!
“Introduce reporting and measurement procedures. How many faults were reported this week? How long did it take, on average, to resolve them? What has been done to reduce the risk of the same fault occurring again? It's crucial to have the right data in order to make informed decisions.”
Why not trust your technical team and let them have their glory instead of micromanaging them. It is obvious you cannot write the code or build the systems so let them do their job. Managing technical teams by the numbers is JUST awful and is 1980s mentality. You should use feedback management styles – not by the numbers. This is why Japan’s automobile market took off and America’s died.
I learned a long time ago to throw out corporate management ideas about how to manage techies and I am so glad I did. My teams have been successful and my linked-in is full of former employees and colleagues who want to work with me again.
Thanks for at least speaking out and making an attempt to understand a very hard group to manage. The problem with them ... most of them are probalby smarter then you and I. That is probaby why they avoid management altogether.
The bit you perceive as micromanagement is nothing of the sort. I've been in a situation where schools were needlessly complaining about the technical team, so I introduced such measurements. After a few times of a complaint from a school being met with "Last week 98% of faults were solved within one day, and you yourself rated the visiting technician as excellent", the complaints completely stopped.
Apart from that, we live in an age of austerity, in which top management is continually on the look-out to save money wherever it can. The only way you can protect your team from being outsourced, or reduced by people being fired, is by being able to prove that they are (a) essential and (b) doing a fantastic job. It's not a matter of whether a manager trusts his/her team (I always trusted mine implicitly), but of how other people perceive them and their value to the organisation. I think that a good and caring manager will make sure that the team's rating in everyone's eyes is not only excellent, but can be objectively proved to be so.