Keeping GOV.UK running takes a lot of work. Like any website, it needs maintenance. And, as an important part of national infrastructure, it’s crucial that it has a team of people available to respond quickly to any problems as they happen.
This is where the Technical Support team comes in. Technical Support is a term used to describe the team who are on call to deal with technical problems like outages, and the day to day running of the site.
This team responds to any alerts that come through the automated monitoring services or via the ticketing system. This team is important: it’s responsible for keeping GOV.UK running.
Despite the important work the team does, it had a problem: no one wanted to be on it.
The team no one wanted to be on
At GOV.UK, the Technical Support team is made of GOV.UK developers and infrastructure engineers working to a rota. Each of GOV.UK’s twenty or so developers takes a turn to work in a team of three, rather than allocating the work to a dedicated team.
In theory this works well for several reasons: the team is staffed by developers who have a good working knowledge of the systems they are dealing with; and by taking their turn on support, junior members can quickly learn more about common problems across the system.
In practice, this wasn’t working so well at GOV.UK. The fact that people didn’t want to take their turn on the Technical Support team had its roots in related problems.
First, the team didn’t have an identity or culture of its own. This became a problem when the rota system meant that people could quite often be working with people who they had never met or worked with before. This also posed problems for continuity and ensuring knowledge wasn’t lost week to week.
The second problem was that people had got into the habit of farming out repeatable tasks to the support team rather than deal with them within their own teams. It had become common for developers to say ‘let’s leave this to tech support’, even when they were the people who made up Technical Support. This meant they weren’t owning technical problems that needed to be solved and it was being used as a repository for routine stuff which should have been managed by other teams.
There had to be a better way of doing this.
What we did
To begin with we tried to tackle the lack of shared culture. We did this by holding a series of workshops and then writing a team charter. Collectively we laid down what the Technical Support team members’ roles and responsibilities were.
We established ‘rules of the game’, that made explicit how people should behave when working their shift on the team. This included practical things like when the working day would begin and rules around how many people should be available at all times. What resulted was a brief document of 7 bullet points:
- tech support is a learning experience, you should aim to learn more about how GOV.UK operates during the week
- work together, be inclusive and don’t leave anyone out or alone
- it starts at 9:30, be there
- feel free to go to essential meetings, but tell people ahead of time and see item 2
- make small improvements to make it better for the next team (e.g. documentation, automation)
- there’s no such thing as a stupid question
- help others and be patient - not everyone knows the same things
Making sure everyone knows the rules
Having these things written down made it much easier for developers to quickly slot into a shared culture. It also meant team members were comfortable calling out behaviour that deviated from what was agreed.
Alongside this, we made a conscious effort to emphasise the positive impact made by Technical Support.
The weekly routines
There were practical measures we put in place too; at the end of the shift it became the Technical Support team’s duty participate in a handover meeting with the next shift.
We also put in place a weekly retrospective to look at the things which hadn’t gone to plan and anything we could improve on. This ritual is now part of the handover meeting.
Alongside this, we identified the repetitive tasks which had been assigned to Technical Support and worked on finding ways for the teams responsible for them to automate them were possible. This meant Technical Support could use its free time pursuing more proactive means of keeping GOV.UK running smoothly.
Lessons for other teams
As is often the case, the challenge was partly technical, partly cultural. This is what we can take from it:
- involve the team in any changes - they know what they need to do
- do everything you can to make it a team, even if it’s only for a week
What we tried to do was to create an environment where there was a clear team, and everyone knew what was expected of them. We involved the team in all the changes, and we started with the team charter.
Keeping the 180,000 or so pages on GOV.UK working will always be a big job, and with it there will come problems. But at least we’ve now made it a job people want to do. Since making these changes, people are now happy to take their turn on the Technical Support team.
Join the conversation on Twitter, and don't forget to sign up for email alerts.
4 comments
Comment by Anonymous Also posted on
This is great to be honest!
Comment by Anonymous posted on
Not really. But after you've had a few major incidents, I think you'll get my point.
Comment by Anonymous posted on
So, the front end website for UK government:
- still doesn't have either effective tech support
- people who understand what tech support actually means
- people who get why not having it could be an issue
And you want to build ID and payments platforms for government?
You need, as a matter of urgency, to bring in people with an operational background
Comment by Stephanie Richardson-Dreyer posted on
Hi there,
The article is about how we improved the culture and effectiveness of technical support on GOV.UK. GOV.UK values and encourages continuous improvement and so focussing on this team’s effectiveness to provide the best possible level of technical support was important. The problem we had was the developers in product teams didn’t always see the value in being in a technical support role, and we’ve changed that perception by making it clear how important technical support is for GOV.UK and its users. Some of the changes we made have resulted in product improvements to GOV.UK's publishing systems, which reduces the reliance that Publishers have on us for technical support.
Thanks for your feedback, I hope this response shows that we have effective technical support on GOV.UK and that we’ve created a culture that keeps the team committed and effective.
Many thanks,
Stephanie