Monzonaut AMA - Jen - Knowledge Management Lead šŸ“š

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! :wave:

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:

  • 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?

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).

1 Like

Can you point us in the direction of what this is?

Absolutely :slight_smile: 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 :slight_smile:

1 Like

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!

1 Like

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.

6 Likes

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:

  • Creating system-level documentation that covers multiple components working together on one thing, like a particular feature
  • Providing entry guides on overarching topics that cross whole systems, like our coding conventions, or how to deploy a change

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 :wink:

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 :wink:

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:

  • A proposal outlining the problem weā€™re trying to solve, a suggested implementation with the measurements weā€™ll use to figure out if itā€™s worked, and an assessment of the risks and possible mitigations we need to consider
  • An approval or discussion in an architecture review meeting
  • A series of decision records as the project progresses
  • A detailed README and implementation docs
13 Likes

Brilliant questions. My publisher will love this :wink:

4 Likes

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 :clap:

11 Likes

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.

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?ā€™

8 Likes

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.

3 Likes

Not at all :smiling_face: 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!

8 Likes

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.

2 Likes

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.

3 Likes

Thanks @jenwilkinson for your comprehensive and insightful answers! A lot to mull over :smile:.

4 Likes

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.

2 Likes

Thanks for the great questions. As you can probably tell, I love to chat about this stuff :smile:

Feel free to keep firing questions over!

2 Likes

:rotating_light: Today is the last day to ask @jenwilkinson questions :rotating_light:

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 :thinking:

5 Likes