I never came across Ocelot in my time in gov, but Iām sure the support teamsā needs are very similar.
My time was mostly spent helping other engineers across the civil service understand how to use the tools and platforms that GDS built. And in a meta way, also how to handle their own documentation. We ended up building our own tech stack for docs using a ādocs as codeā approach. Hereās an old blog post I wrote about it a few years ago.
At Monzo we have an off-the-shelf product for COps knowledge that only contains information relevant for COps. It makes it a lot easier for them to find the information they need as itās designed with them in mind from the very start.
I was going to ask how do you make Monzonauts (with emphasis on those that donāt work in technical operations) actually read the documentation, but this is answered - in part at least - in a reply further down.
My own personal experience with this kind of thing is where I am at the moment Iāve built pages in Confluence that cover specific topics that come up repeatedly - Slack, tickets, whatever. I spend ages building the pages. I include screenshots. I keep the language simple and with as little technical jargon as possible. I cover different situations and how to deal with them. But then, on Slack usually, Iām bombarded with the same questions over and over again despite everything thatās been done to promote the documentation.
Thatās a tough situation. Iāve been there! It sounds like youāve put a lot of effort into creating these docs so it might be useful to investigate further. I donāt know if you want advice, but if you do, Iāve put some thoughts below.
Have you asked these folks why they donāt check the docs first? Do they know the docs exist? Can they find them? When they find them, can they quickly find the thing they need? Do they trust the information in those docs enough to base decisions on? If the answer to any of these is no, you have a place to start.
If the answer to all these is yes, thatās great, youāve got some good content on your hands. For your docs to be successful, they have to be better (faster?) than the alternative route of asking you for help. My assumption here is that your colleagues like that route because youāre a helpful person and it gets them a quick response. Do you always help them straight away? Do you point them at the docs first and only give them answers not covered by the docs? Do you do this in an open Slack channel rather than private messages? If people see that the docs are there, helping others, and that you wonāt help someone until theyāve consulted the docs first, it can nudge them to do the same.
Hi Ben! Apologies I missed your question earlier in the week. This is a good question. Our data protection and data governance teams look after much of this. We have a bunch of processes and tools in place, but itās something weāre always improving.