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.