Hi @jenwilkinson!
What systems do Monzo use to manage things like document retention and disposal of personally identifiable information? Are you using or planning to use any of the ML tools on the market?
Hi @jenwilkinson!
What systems do Monzo use to manage things like document retention and disposal of personally identifiable information? Are you using or planning to use any of the ML tools on the market?
Hello Jen!
Can you talk a bit about how government compares to Monzo? Was it a difficult transition?
Hi Jen!
Interesting to hear about your time at the GDS, and the work you do. I suppose my questions are:
And in relation to this respone:
In the last year, weāve invested heavily in improving this. Thatās included things like moving all customer support docs to its own dedicated system that is much easier to search
Iām not sure what system you used in the GDS (I myself have some experience in Ocelot), but do you find that private sector lends itself to a more agile rather than a process driven approach when it comes to updating COps policies?
Okay googling has me at a standstill.
Iām ruling out the animal (unwisely?) so my shortlist is a Microsoft API framework, an accountancy package for content producers and AI driven higher education software (no me neither on that last one).
Can you point us in the direction of what this is? (If itās a secret government code name then I have screenshots and know where the MI5 building is).
Can you point us in the direction of what this is?
Absolutely itās a web based portal for COps. Not sure who developed it, but itās used by 3 departments I know of from a 2021 Office for Tax Simplification release. I just made a link between simplifying that and streamlining COps within banking
Iāve not used it myself in quite some years but it seemed quite useful, but of course my experience is that the private sector is more agile and so might not need such a system - I probably didnāt word my question that well though, so Iāve done a wee rewording to help
Sweeping! One for Jen maybe, but I always thought of old government departments like the HSBCs of this world, with GDS a bit more of a Monzo.
Keen for insights!
Possibly at some point it was, but definitely not now
Hey Peter! Absolutely. It was weirdly easy.
As I think you mentioned in another comment, GDS feels a lot like Monzo and vice versa. When I first met Jonas, it was actually one of the first things we chatted about.
GDS feels very different from other departments. Everyone is there because they really believe in making digital services better for the public. The same is true for Monzo. Folks here believe really passionately about making it easier for people to handle their finances. No one looks forward to having to interact with the government or their bank. Usually when you do, you just want to get something done so you can get on with your day. Working with people who understand and empathise with that sounds basic, but contributes to everything both organisations do.
Where it feels different is the speed at which Monzo can move. In gov land, everything needs a lengthy business case, there are mounds of red tape, and thereās always a committee for a committee for a committee involved somewhere.
At Monzo, anyone has the genuine autonomy to pitch an idea, get feedback, and run experiments to find out very quickly whether something is worth investing in. And if we find out something hasnāt worked, thatās a great result for us because we know itās not worth our time and effort. Thatās not to say there arenāt checks and balances in place, but the difference is that youāre working with the system, with the regulations, not against red tape that exists for the sake of it.
Oh my goodness. What amazing questions! Ok here goesā¦
We have a central catalogue of all the components that power the bank. Think of it like a big long list of all our microservices, web apps, and cron jobs etc. We have an internal developer portal that helps people search that list and find information associated with each component. That could be docs about what the component is, or the microservices upstream or downstream from it.
The source files for that component documentation live in GitHub alongside the code and we use the same processes for reviewing documentation changes as we do for reviewing code changes. Iām a big big fan of ādocs as codeā for many reasons, but the review flow is a big part of that.
Everyone at the company has access to the internal developer portal. We also have a central knowledge base (kind of like a company wiki) that the rest of the business also uses.
If you mean service RPC definitions where those services interact with other things then yep! We have strongly defined types. In some places and for the most critical services, we have more detailed API docs, but we need to improve how we handle these and make sure we always provide more contextual information beyond a name and data type.
So with so many components this gets a little tricky and we have to take a pragmatic approach to documentation. Youāre never going to be able to comprehensively document every single little thing and keep it all up to date, and thatās ok. Our time is often spent better elsewhere. However, each component will have at minimum a very short description of the āwhyā in its README and some links to related documentation. Iād consider that part of our āminimum viable docsā criteria.
Each component is owned by a team rather than an individual. They are responsible for the documentation as well as the code and everything else around the running of that component or collection of components. If someone leaves, ownership of the docs remains with the team.
Minimising the risk of people leaving with critical information and institutional knowledge is really hard and sort of why my job exists in the first place! We encourage teams to document throughout the software development cycle, contribute regularly to talks and knowledge-sharing sessions etc. If someone does leave with some important knowledge, we try to make as much time as possible for them to document before they go. And if theyāre replaced, the new Monzonaut is the perfect litmus test for those docs and to find any knowledge gaps we still need to fill.
Yep! We usually link to the original RFCs (what we call āproposalsā instead) as part of the docs so folks can see the original justification or design behind the system or component. Thatās really great, but difficult if you want to understand to what extent the original proposal was implemented and where it differs or why it differs. That additional knowledge is sometimes missing and one of the gaps we want to focus on improving this year.
Solid question. I am loving these! So youāre absolutely right that you can go very deep on certain topics, particularly on a service by service level. But often, our engineers arenāt looking for service-specific information. They typically have some kind of task-based question they want the answer to. In those cases, we need more horizontal documentation that cuts across different parts of our architecture like you suggest. We tackle these in a few ways, by doing things like:
Those docs are kind of like ālanding pagesā for the topic. They give an overview of the concepts needed to dive in then act as sign posts to the most relevant content. They tend to live in our central company-wide knowledge system as theyāre often useful for everyone in the business.
We do auto-generate some of our docs, though not as much as I would like. Weāll be exploring more automation in future. In some cases we do auto-generate diagrams too, which is always good to see. Thereāll always be a need for human-generated docs though, often to provide the missing āwhyā behind an implementation or flow.
Not as much as we should! New joiners are given a tour through our different knowledge systems and given guidance, but I ran some recent user research that showed this isnāt enough. One of the projects Iām involved in at the moment is overhauling our entire engineering onboarding experience. A big part of that will include introducing our conventions and being given the chance to contribute to our docs much earlier. I also run ad hoc training with individual teams or individuals.
From our research, usually by searching our internal developer portal, company-wide knowledge system, or grepping a bunch of files. Findability is really gnarly so weāre always looking for ways to make it easier. Sign-posting to relevant docs and deleting/archiving old information is sometimes the most effective way to keep on top of this. Iām sure our engineers are very tired of hearing me witter on about the power of the delete button
We have a marvellous writing team who maintain our āTone of Voiceā, which sets expectations for any kind of writing at Monzo. A big part of that is making sure we use plain language and avoiding unintuitive terms. Youāll often see feedback on pull requests or in proposals suggesting name changes or checking if the user of the thing will be comfortable with the terms.
We donāt maintain a central glossary. Iām sure there will be knowledge management people reading this and flinching at that. While the motivation behind them is good, glossaries put the onus on the reader to go hunting for info. In our view, it should be down to the writer to make it easier to be understood. If you rely on a glossary within a team itās a sign your terms maybe arenāt common enough to be understood and if lots of people are struggling to understand your terms, itās a sign you might want to design/re-name something or provide better contextual information to help them understand. Also maintaining glossaries is a nightmare and not how anyone wants to spend a Tuesday
This might be my favourite question of them all. For our git-backed docs, documentation pull requests get the same scrutiny as code changes. We treat them exactly the same.
Youāre absolutely right that half the battle is getting out of your own head to think about what your reader needs. Thatās the old ācurse of knowledgeā thatās so hard to shake. Documentation reviews help that, but we also do user research internally to check what people need to know about a thing and during our documentation training we always challenge writers to think about what skills, experience, knowledge, or access someone needs in order to understand and work with the thing weāre documenting. Taking just a few minutes to think about that before putting pen to paper (or hands to keyboard) is really impactful.
Weāve also introduced the start of some automated quality assessments. We have a system called āsoftware excellenceā that looks at our components and assesses them against certain criteria. It generates a rudimentary āgradeā to let teams know how their components are doing and help them figure out where to spend their time improving existing things. Part of that āgradeā is calculated using some very rudimentary documentation measures. For example, how recently the docs were updated, and whether our prose linter has flagged any readability issues. Itās by no means perfect, but is extremely useful in prompting conversations about what makes good documentation and where documentation improvements are needed. Iāve got some big plans to make this more useful for engineers so will pop onto the blog when weāve improved this.
I was really trying to avoid the answer of āit dependsā but it does depend! Broadly speaking itās likely weāll use a mix of documentation artefacts or knowledge-sharing practices for a piece of work. That could be:
Brilliant questions. My publisher will love this
I just want to say how appreciated it is that you took so much time and effort to write such a detailed response to the questions from Duncan
Hi Jen!
Interesting to hear about your time at the GDS, and the work you do. I suppose my questions are:
- What skills/knowledge/experience translated best in the migration from CS to private?
- Did you find the culture massively different, or more samey than you expected?
Hi Andrew!
Skills = writing good business cases/proposals. Being able to articulate a problem and a proposed solution in a way that is meaningful to someone who may be removed from the detail is so important.
Knowledge = the inner workings of weird legacy software. Being able to interrogate the trade-offs engineers have to make on a daily basis.
Experience = Probably project managing big content projects, like migrating to new tools, and learning how to facilitate good training.
And in relation to this respone:
In the last year, weāve invested heavily in improving this. Thatās included things like moving all customer support docs to its own dedicated system that is much easier to search
In the civil service it sometimes felt like running a series of sprints wearing shoes that were too small while people threw projectiles at you. At Monzo, weāve got to run the same distance, but the shoes fit and your supporters are actually cheering you on. Mentally that makes such a difference.
I explained some of this in a different answer, but the biggest change for me is not having to constantly defend my profession and value. At Monzo, itās a given that good knowledge-sharing is beneficial for the organisation. A lot of the improvements good knowledge practices bring are intangible. They donāt always fit neatly on a graph trending up or down. It takes senior leaders that believe in the value of the marathon and understand that itās going to take time. We have significant documentation and knowledge debt to pay down while introducing new practices to keep up with the sheer pace the rest of the company is going. I fully credit our engineering leadership for always championing that work. Itās so refreshing to move beyond the āWhy should we bother?ā question and get straight to āOk, so how are we going to improve this?ā
Can you point us in the direction of what this is?
Absolutely itās a web based portal for COps. Not sure who developed it, but itās used by 3 departments I know of from a 2021 Office for Tax Simplification release. I just made a link between simplifying that and streamlining COps within banking
Iāve not used it myself in quite some years but it seemed quite useful, but of course my experience is that the private sector is more agile and so might not need such a system - I probably didnāt word my question that well though, so Iāve done a wee rewording to help
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 just want to say how appreciated it is that you took so much time and effort to write such a detailed response to the questions from Duncan
Not at all Itās lovely to be chatting to you all. Shoutout to the brilliant @AlanDoe for suggesting this AMA.
Iām usually lurking on here looking for blog post inspiration. Any ideas most welcome!
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.
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 @jenwilkinson!
What systems do Monzo use to manage things like document retention and disposal of personally identifiable information? Are you using or planning to use any of the ML tools on the market?
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.
Thanks @jenwilkinson for your comprehensive and insightful answers! A lot to mull over .
Thanks for the great questions. As you can probably tell, I love to chat about this stuff
Feel free to keep firing questions over!
Today is the last day to ask @jenwilkinson questions
Although I feel we could convince her to stick around and maybe we need to look into something like a āRequest a blogā kind of Topic for future