This week we’re joined by Lara Hogan – author of Resilient Management and management coach & trainer for the tech industry. Lara led engineering teams at Kickstarter and Etsy before she, and Deepa Subramaniam stepped away from their deep roots in the tech industry to start Wherewithall – a consultancy that helps le...

It’s easy to overlook documentation when building an application, but documentation can make or break a consumer’s experience. Today we’re diving into the world of documentation to discuss what it takes to write good documentation, the ethics of documentation, and some popular tools you can use to g

Rachel Tsang and Ross Ferguson share how the GOV.UK roadmap contributes to GDS’s mission of building a simple, joined-up and personalised experience of government. The transcript for the episode follows: -------------   Vanessa Schneider: Hello and welcome to the Government Digital Service podcast. My name is Vanessa Schneider and I am Senior Channels and Community Manager at GDS. For those of you who tuned into last month’s episode, you’ll know that GDS has launched its new strategy centring around 5 core key missions:   GOV.UK as the single and trusted online destination for government information and services;   Joined-up services that solve whole problems and span multiple departments;   A simple digital identity solution that works for everyone;   Common tools and expert services;   and Joined-up data across departments.   Today I am joined by Rachel Tsang and Ross Ferguson from the leadership team of the GOV.UK programme to hear more about how their roadmap objectives are contributing to making GDS’s mission - of building a simple, joined-up and personalised experience of government for everyone - a reality.   Ross, could you please introduce yourself?   Ross Ferguson: OK, thank you. So I'm Ross Ferguson and the Deputy Director for Portfolio Delivery within GOV.UK. And this is actually my second tour with GOV.UK. I started as an Associate Product Manager when GDS was first set up. GOV.UK was the first product that I worked on and I later worked as the Head of Product Management for GDS. And then after a little overseas tour, I was very pleased to return to GOV.UK in January and, yeah, very excited to be back and to be working with Rachel.   Vanessa Schneider: It's good to have you Ross. Thank you. Yes, Rachel, would you mind introducing yourself to the listeners, please?   Rachel Tsang: Of course. So my name is Rachel Tsang and I am Deputy Director for Governance and Assurance on GOV.UK. Like Ross, I am, I sort of boomeranged back to-to GOV.UK. So I was, I did a previous role and then stepped away to do something else. And I'm really, really thrilled. I think that's a, it's not a necessary condition to working on GOV.UK that you come back. I think it is testament to like just how much people enjoy working, working on GOV.UK. Before that, I so, I joined government as a Social Researcher and did a range of roles in different government departments and yeah, have settled here in GDS.   Vanessa Schneider: Thank you. So as mentioned at the top of the episode, the GDS strategy strongly relies on GOV.UK as outlined in GDS's first mission, which is to establish GOV.UK as the single and trusted online destination for government information and services. It'd be really great to hear from both of you how this mission influenced the update to the GOV.UK roadmap.   Rachel Tsang: So I think fundamentally our mission for GOV.UK is to provide a joined-up, personalised, and, and proactive service - we-we blogged lots about that recently. And we-we've evolved continuously since GOV.UK was first created in 2012. And what we're looking to do now is really a big step change in-in our offering for GOV.UK. Fundamentally, it's-it's about changing our offering to continually innovate to meet changing needs. I think that that is the crux for how we're feeding into the wider GDS strategy and vision.   Ross Ferguson: Yeah, absolutely. I think departments, GDS with GOV.UK and, you know, spend control standards alongside departments has done a really, really good job over the years of bringing services that were previously paper-based and office-based, online. And a lot of them are really great in isolation. But we know that the people who use GOV.UK don't experience them, don't want them in isolation. They don't, it's not a nicely compartmentalised linear process. You know, they-they want them in combination. So really, the next maturity step for Government Digital has to be that these services are joined up. Which means that departments need to coordinate with one another.   GDS is in a great position and GOV.UK is a great platform for, for enabling that join-up to happen in a coordinating sense but also in in a public experience sense: that there is one domain that the public knows they can go to to get the guidance, to get access to the services. And, you know, that's what they would expect in all other walks of life when they're transacting with lots of, you know, utilities and and and entertainment. So it's perfectly reasonable that they should expect that from government, and government is perfectly capable of doing it. So that's work that we want to really accelerate this year. And, you know, it is a big undertaking. So it's something that will continue in the, in the years to come.   Vanessa Schneider: Yes, speaking of joined-up services, I'd like you to listen to a couple of interviews that we recorded with colleagues in the different GOV.UK teams that are working towards the objectives of the roadmap. So first we’ll actually be hearing from Tina Mermiri, who shares about the work done to connect insights across GOV.UK to enable those joined up services. This is so that government understands its users and users understand the government.   [Start of vox pop]   Tina Mermiri: I'm Tina Mermiri, the Head of User and Data Insight for GOV.UK. I set out the data and the insight strategy for the programme, and I oversee all the work within data science, performance analytics and user research. So as a team of experts, we have 3 wider objectives and that's understanding GOV.UK users and their needs; that's facilitating data-driven decision-making internally and across wider government; and it's also monitoring the impact of the work that we deliver and the products that we ship. So with performance analytics, we're looking at how people, or users engage with the site, what content they're engaging with and how we can optimise their journeys.    Then we complement that with the user research to understand what their issues are. We get feedback from them. We're actually looking at why they're trying to do certain things that are, that are failing and how we can optimise those journeys as well. And so what the data science community does is go into a little bit more detail with some of the more complicated techniques whereby we might want to look at some of the data that we've got behind the scenes and create some models and scores and look at something like related links and surface them on the site for users that have done something similar to other users and make their journeys easier. So it's all going back to optimising the journey, making it as smooth and frictionless as possible with the power of data behind that.   We're using Google Analytics to power a lot of this data. And Google Analytics has a cookie consent. So we will only track people who have opted in to tracking, which means that our data is not 100 percent representative of all our users, but it's pretty indicative of what they'll be doing. It also means that we hash out any personally identifiable information. We don't actually track that and don't use it for any of our analysis. And we've worked really, really closely with the privacy team to make sure that, you know, privacy is at the heart of all the tracking that we do and all the consequent analysis that we conduct around it. So personalisation, the way that we're looking at it is two-fold. On the one hand, it is without any personally identifiable information. So it is just looking at common journeys and similar content that's being consumed by different users at aggregate level. So that's the one way of doing it where we don't collect any other personal information and we don't personalise it based on their background or any of the demographics, we don't even track that right now. But it is about that journey and other similar journeys. And then on the flip side, we will eventually be trying to do a little bit more personalisation based on people who hold accounts with us, where they will, again, share some of their information with us as part of their account. And that is information that they will have opted into as well. And we will hopefully use that to personalise further, based on, based on their location, for example, and other similar attributes that we want to start building on.    The nature of the data that we collect and making sure that that's representative is, is very, very important. So we could do a lot of really clever stuff with it. But if it's not in a good place, then the output-- if the inputs aren't reliable, necessary, then the outputs won't be as reliable either. So we're spending a lot of time on revisiting the way that we collect some of the data, the way that we cleanse the data, the way we make sure that it is reliable and ready for us to use. So that's one thing that we're investing in quite heavily. And we need to make sure that we're asking the right questions without, like, probing, leading wording. We need to make sure that we're able to differentiate between attitudes around, let's say, GOV.UK or what they're trying to do and wider government. We need to make sure that our data is representative across all our very, very wide range and diverse users.   I think the work that we're trying to do and the opportunities that it opens up for users and to make their journeys easier is, is, is really impressive.   [End of vox pop]   Ross Ferguson:  Tina's a...and her crew, you know, clearly, clearly know what they're talking about. She was, she was giving great insights there into, you know, just how important the data usage is going to be to powering the sort of whole journeys work that we’re wanting to do, the personalisation. It's all, it's all dependent on us making, you know, proper, proper use of that, of that data. I think that she, you know, she did talk well about the tooling that we're starting to bring in to help us with that. We are, we're definitely stepping up the recruitment that we do of-of these data disciplines. And, you know, and I think it's about bringing our, the, the data scientists and engineers that we have already and have had for a while much more closer into the work with the with the team so that they're they're kind of doing less reporting and they're doing more in terms of the tactics and the and the strategy work.   Rachel Tsang:  On the objective to connect insights, I'm not sure we're allowed to have favourites, but this one is-is really, really important to me because I think it really goes back to the heart of why GOV.UK was first created. Right? You think about the world before 2012, where there are almost 2,000 websites, and you needed to understand the structures of government to interact with it. And so we've come a long way. But fundamentally, the way that we analyse and approach problems remain siloed by departmental boundaries. So you know, the work that we are looking to do over the next year to join up those insights, to be able to understand aggregate trends and patterns, that's super important, not just for GOV.UK like in helping us to improve the product, but for the rest of government more generally in terms of how we approach a much wider whole user journeys.   Vanessa Schneider: And I guess as with any insights, what’s important is what you use them to enable. I think it’s time to hear from Daisy Wain, one of our Lead Performance Analysts, about what we’re doing to translate insights into a more personalised and proactive service for users.   [Start of vox pop]   Daisy Wain: My name is Daisy. I'm the Lead Performance Analyst on GOV.UK. It's my job to make sure that we are at the cutting edge of analytical technologies and practises to make sure that we're aligned with what the latest developments are and to make sure that they're fit for purpose, for what we want on GOV.UK that obviously has a strong focus around privacy and security.   So one of the things that we've been doing is doing a cross-government data commission. So it's been working as a small team to find out all the different transactional services there are in government, what data attributes they all collect, and if they have an account that's associated with that transactional service. And if they do, how many accounts there are, and all that sort of thing. And obviously what that allows us to think about then is how we can use that data to be proactive. So, for example, if we were to have, if we were able to know somebody's postcode or to know their date of birth, we can then start to infer things about them. So that means we can proactively show them things on GOV.UK that are specific. So, for example, we know you live in Scotland, we can show you the Scottish content first and foremost, as opposed to the English. What else we can do is obviously helping the product teams to deliver the first trial of the account. So that was what we did on the Brexit checker. So that was the product where any person could go through a series of questions related to their personal circumstances around, you know, where they live, what their nationality is, what their plans are for business and for travel, and what the output is, is a series of actions that you may need to take related to the changes related to Brexit. And the account allows you to store that information, to revisit it and to get notifications of when that might change. The job as an analyst is to look at how people are using that thing so we can look at the sign-up journey to see perhaps where certain steps might not be working as well. And then that starts to help us build a picture about the types of people that would like to use this account and where the value is.   I think it's important for us to think about developing this, like, next generation of GOV.UK and how people interact with government and government services. But it can't be designed just for people that want that. We have to consider people that would not want to opt into that world and to make sure that we are still designing things that allow people to not have to consent, but still have that optimised journey based on the data that we have available on those people, which is non-consented, kind of basic, so from the server. Obviously this is an important aspect for people that don't want to have that universal government sign-in, which is completely, completely within a user's discretion. So from an analytical perspective is, what can we learn about your behaviour on GOV.UK that allows us then to personalise your experience and even be proactive. It could be that you have the option to save some of your preferences. So there's things that we can start to do, which is purely based on your behaviour on GOV.UK that we can say, “hey, we think this might be useful for you” purely based on this behaviour, and then you can opt in to say, “actually yeah, that's handy. I want that to happen. I want that to persist”. Or you can equally say, “no, I'm not interested. I just want it to be, I want to be completely anonymous”.    I also think that some of the biggest hurdles around this is making sure that users’ experience reflects the reality on GOV.UK. There is an expectation, I think, around - for some users - that government is government and everything is joined-up behind the scenes. And there is a confusion around “why do I have to tell my, the tax service my personal details and I have to tell the-- things related to my vehicle, the same details. Why are they not joined up? Also, why can't I sign into this thing and do the other thing?” So the hardest thing is like how can we build something that has those privacy concerns at the centre, but also then reflects users’ expectation of how to, how to interact with government. Meeting those expectations but from our perspective of delivering it, it's how can we do that kind of crosscutting, bringing all of government services, different departments together, creating this kind of, almost this single sign-on vision, which is what we're hoping to achieve in the long term, where you only have to do things once. But how you do that is very, very challenging. The front, the front of it looks simple. The underneath is horribly complicated.   [End of vox pop]   Vanessa Schneider:  I think one of the areas that really impressed me was how much collaboration there is across government on it. And essentially that you've got this buy-in on this objective through the commission.   Rachel Tsang: Definitely. I think we were saying before, this isn't just a project for GDS or for GOV.UK, right. It-it only really, really works, and you only get the real value for users if you're enabling that cross government collaboration. And to be honest, that-that is tricky because departments don't necessarily always have the same priorities; there, there is a lot of stuff that is happening across government. But I think we all have the shared objective of fundamentally making things better for our users. And I think the extent to which this is driven by data and driven by insight is incredibly powerful, right? Because it's all very much evidence-led and led by what is going to make a difference to meeting user needs.   Vanessa Schneider:  Definitely, and I think, again,Daisy also reiterated something that Ross mentioned before at the very beginning, actually, about how the user perception of GOV.UK isn't that there are these separations between the different departments, that it is just the monolith of government and how we're really trying to make that perception of reality. I was just wondering if you had any more reflections on that, Ross.   Ross Ferguson: I think that GOV.UK makes it possible to engage with and transact with government as-as one thing, if-if that's helpful to you as the, as the user. But it is also possible to say you're a-a particular-an academic or maybe a business user - there are you know, we also do cater for those more specialist journeys through, through government as well. I think that's one of the things that GOV.UK has over the years put a lot of effort into, listened to a lot of user feedback, made use of the data that we have had to get that to get that right. And so I, you know, I like what Daisy was pointing out there that: when we're thinking about personalisation, we're thinking about it like, you know, individual needs and that somebody might be operating, coming, coming to GOV.UK, as you know, a private citizen, but they might also be a business owner. And, you know, we-we-we want to be able to-to cater for those different sorts of profiles that one person could-could have. And, you know, and that's what we, that's what we do well. We--is the care and attention we pour into these kinds of nuances, these-these complexities. These--Daisy's right to say that it's-it's complex. That's what we love. That's what we're here for. That's what every person on GOV.UK is here for, you know, to-to do that hard work to-to make, to make the things as simple as people need it to be for their circumstances.   Vanessa Schneider: And it's also beautiful how you're working at it from both ends, whether somebody wants to fully connect all of their personal information that government holds, make sure that everything is bespoke to them, or if somebody prefers to really just have that interaction standing on its own, and just as they need to be in touch with government, they'll handle it on a case by case basis and and just sort of like be shepherded down the right path without government necessarily knowing everything about them.   Ross Ferguson: Yeah, I think that there is so much that we can do with all the data that we generate automatically through, through our logs and that we've gathered over the over the years and that we can analyse very quickly to be able to make pretty good bets about other information on GOV.UK, other services that would be of interest to you based on the patterns of usage in a given session. Which is, you know, very unintrusive. And, you know, I think that there's lots that we can do without people telling us lots of attributes about themselves and having to sign up to things - that will always be at the core of GOV.UK. However the account is very exciting because it will put the user in the position of being able to say, to build up a profile for themselves and be able to choose how they then use that, and that will just make government work so much harder for the public.  And I think that that is maybe a little bit of, has been a pipedream for many for many years, but it's a reality that we can that we are delivering now, that will start to see come to fruition over the next year. And I think the public will be really excited about that and it will help make government more efficient. And so I think that's-that's something that everybody wins from. And really, you know, the teams are excited about that, not just the account team, but all--that's one of the good things about what I'm seeing on GOV.UK is the way that the teams are working alongside one another. There are data insights teams that have been really proactive about how they get in touch with our team that's working on starting and sustaining a business journey. They're saying to the accounts team “look we could, we could really benefit from this functionality, this feature, can we share data on this”. Vanessa Schneider: We obviously need a really solid foundation for all of this work, so I guess that’s why our objective to ensure GOV.UK is always available, accessible and accurate is so important. Let’s hear from Kati now on what’s happening in that area.   [Start of vox pop]   Kati Tirbhowan:  I’m Kati Tirbhowan, I’m a senior content designer in the GOV.UK Explore team. Our team is working on making GOV.UK easier to navigate and we’re currently working on ideas that include improvements to the site-wide navigation, mobile experience on the site, page-level navigation elements, so things like how the breadcrumbs and related links work on the site.   In our team we run multiple rounds of user research to improve our designs and we're doing research with different types of users. That's people who come to GOV.UK for different reasons to do different things. And within those groups, we're also including users who might have low digital confidence or skills or access needs, for example. And then each discipline brings their expertise to make content accessible. So that's from design to developers, to content design. And for content design, for example, we've got our content guidance that includes an accessibility checklist that we use to design and review content changes as part of our regular work on the site.    And in our team we've also just done some accessibility testing on the new site-wide main menu design, which is one of the ideas we're working on. And to do the testing we used accessibility personas the GDS accessibility team have created and those personas are really helpful and an engaging way of raising awareness and understanding of accessibility. And from that, we identified some improvements we can make to the design and we'll continue using those personas to test our work as we go on. Um we’re also optimise-- mobile-optimising the pages and components that we're working on. So they feel like they're designed with mobile in mind, and that includes things like expanding the touch target. So the area you need to tap on to follow a link so that they're larger and easier to use, um especially for people who have a tremor or a long term impairment, for example.    I think one challenge is the size of GOV.UK. It's a huge and varied site, with many different types of content, and GOV.UK provides the route to hundreds of government services operated by departments, as well as the guidance published by every department. You also have a lot of people looking for information and services to do important things in their lives. And that means for us it's critical that people can find what they need quickly and as easily as possible. And it really is the hard work of all the teams and all the different disciplines and all the talent that makes it happen.    And one of our design principles is “do the hard work to make it simple”. And I think people are really passionate about this and care about making things work for users the best we can. And I feel like this is a big part of it, making it such a great place to work too. We can help to make a real difference.   [End of vox pop]   Ross Ferguson:  I might point to this one as being one of my one of the areas I care about the-the most. I think getting the basics right is so foundational to the innovation that we might want to put on top of that. It's really important that GOV.UK is there in times of need for people. It has to be reliable. And it's the sort of site that you go to when you're not sure if the internet's working properly, you can go to GOV.UK to see well, if GOV.UK's up then it's and then everything's all right. So we do put a lot of stock in making sure it's reliable, that it's secure, that it's performing quickly and smoothly for people.   And, yes, that-that would--includes how our search and navigation works, how our-our pages help people to find their way around the information services and through it. And so, yeah, we've got some-some pretty major changes taking place to the navigation on GOV.UK planned. That starts with a test, of course, because we like to, you know, to test with users before we go, you know, rolling this out to everybody. We will do some multivariate, or A/B testing, with a proportion of our users on GOV.UK, who will see the site in slightly different ways: so the menu bar at the top will have some, some new options in there. And through the early testing that we've already done, we're pretty confident that's going to help people to find information quicker and then to find other related information if they, if they need it.   A lot of people will want to come to GOV.UK, get the thing that they're after and then get going. But some people will want an ongoing journey. And so this new navigation bar helps people to understand where things are and how things relate to one another. And then later on in this year, that same team, well obviously they'll continue improving that that nav, but they will also then be working on the homepage, which, you know I suppose, it's a kind of a cliche that people say, well, Google is the homepage, but actually, you know, really you know, a lot of people it's actually one of our it's like our top page is the homepage - lots of people go there. And so it can work harder, we think, helping people to understand what's timely, you know relative to events that are taking place in society, maybe or maybe because they've given us, they've signed up to an account and they want maybe a more personalised experience. So we're going to start with some changes to the homepage, which make it clearer what's, what's available and what's timely. And so these will be really two of the biggest changes to the design of GOV.UK, really since-since its launch in 2012. And so we're obviously a little bit excited about those.   Rachel Tsang: Yeah, definitely. So I think fundamentally it all starts with this, right? We support millions of users every day. And to be able to do that effectively, we need the platform, we need the information and services on it being reliable, resilient and secure. You can't have accounts and personalisation without this fundamental infrastructure. And-and so it's super duper important. And I think it also touches on something that's been implicit to what we've been discussing throughout, which is about retaining user trust. And that is inherent in how we need to build the account, that's inherent in how we do personalisation, but it's also inherent in just being available, accessible and accurate.    And you know, we think about the sort of the premise of the work that we're doing now to increasingly personalised GOV.UK, right? We start from the premise of like, well, people's expectations have changed. They think about how they interact with you know, like Citymapper or with Netflix. And-and so our premise is that why should, why should the user experience of interacting with government be any different? That's the starting premise, but for us, it--trust takes on an extra important angle, and this is where having that infrastructure of content, of the platform, of availability is so, so important.   Vanessa Schneider: You're so right, you're so right. But, yeah, obviously what's coming through through all of this is really that it's all about iteration. I mean, trying out new concepts is a part of iteration, isn't it? Like GOV.UK accounts is building on things that already exist. But one of the bigger questions really is the: how everything that we're doing right now supports what the rest of government is doing. So we talked with Anna Sherrington, who is working on that objective within the GOV.UK team.   [Start of vox pop]   Anna Sherrington: Hi, my name is Anna Sherrington and I'm the Lead Delivery Manager at GOV.UK and I'm responsible for supporting the government priorities of the day objective. What that means in practise is that I work with a number of multidisciplinary, highly-skilled teams to ensure that GOV.UK is responsive to the issues of the day and that we are the source of the government is saying and doing and what it means for people day to day.  So there are 4 teams working on this objective at the moment, 2 are concentrating on coronavirus, 1 on Brexit and 1 on starting a business. This means we have around 60 people working on this objective. At the height of the pandemic, we had more people covering our coronavirus work and the team structure has been changing as the situation with the pandemic has developed. For example, last spring and autumn when things were very busy, we had a weekend and late evening support rota in place in order to support any updates as they happened. And although we don't have these rotas anymore, we still have the flexibility and the teams to support plans. So we have really adapted to changing needs for this objective. I feel very fortunate to be working with the teams I’m working with and very proud of the work we do every day. There's a very supportive culture within the teams and we have made it our priority to build resilience and flexibility with everyone's wellbeing at the forefront of our minds. And this has been crucial.   [End of vox pop]   Vanessa Schneider:  A lot has been achieved in the past year first of all, and it's important to recognise that. We've really managed to-to sort of scale up in a way that we are resilient.   Rachel Tsang:  Talking about resilience and being able to meet the government's priorities of the day, I would completely agree with you, like it's been an extraordinary 18 months and it's super important that GOV.UK is, as the online home for government, is able to be able to be comprehensive and responsive to provide support for the government's critical priorities of the day. For-for the past 18 months, that's been Coronavirus and Brexit. And we've seen som,e we've seen some record levels of traffic. So I think during the pandemic we reached a peak of it was around 42 million page views at our daily peak. And that that is truly extraordinary, thinking about how the value and the importance of GOV.UK has grown over time. And I think what the last 12 to 18 months has shown us has really been the value of the value of GOV.UK as this critical source of truth, the value of collaborating across government, we've already talked about that, and the value of making sure that we're providing that trusted, accurate information and support to the millions of people that are relying on GOV.UK.   Ross Ferguson: I am not surprised that given that people on GOV.UK are the sorts of people who will care about pixel widths on things like hover states and, you know, and and and punctuation to almost the pedantic degree - but I would never say that - that come, you know, a national, you know, emergency, an unprecedented event for for the UK and the world, that those people would rise to the occasion. You know, nobody wants a pandemic but thank goodness we had GOV.UK as a place that, you know, the civil servants, and GDS, GOV.UK and then across the government could all use to collaborate with one another in the creation and curation of guidance and services very, very swiftly. But also, you know, and then the public could be given a really clear steer on where they could go.    And so I think that it's been interesting looking at the usage patterns we see, yes, an increase in the number of people overall coming to GOV.UK, but, you know, an increase in the regularity of those visits. So I think that that cross government collaboration that we saw come to the fore during the intense COVID period, paid off. And actually I think that it's, although we are glad that there's not the same urgency, I think that focus on collaboration does need to continue on now for and lots of aspects of running government, but particularly in that digital space where we're, we're good in the UK at digital government, but we're still not meeting our full potential. And so I think if we can keep that focus on-on good public services online, across government collaboration, I think that they, I'm very optimistic about the future for-for the digital government here, here in the UK.   We want to be doing more and we want to be doing better. And because that's what people here in the UK want us to do, and I think, you know, where you mentioned our, our blogs, podcasts, our code is all open. And we you know, we do, we share this so that our peers and other governments internationally also at the local level here in the UK can, you know, can can benefit from that and that we can benefit from their feedback and their scrutiny as well. I think that's-that's one of the things that I think the GOV.UK, GDS, UK dig-government digital does really, really well that that openness, that willingness to share and that drive to keep-keep doing better. And I think that that's what and that's what that gets me really motivated.   Vanessa Schneider: We have now come to our final objective, is: be channel agnostic. So personally, I know we've done fantastic work in collaboration with third parties like search engines in order to link content outside of the confines of the website itself. I was just wondering, maybe Rachel, you can tell us about how such partnerships came about and how this has changed things for users.   Rachel Tsang: Definitely. So I think we, unsurprisingly, are huge fans of-of collaborating. You mentioned that we've done some good work recently with Google to make sure that more GOV.UK content is available through-through rich search results. We also did some good work on the recent local elections as well. And so I think we start from the premise of wanting to collaborate and to think about how we can make more of our content more available.    I think the broader objective on being channel agnostic, I mean, we know that users are increasingly accessing information through other channels. Right? Search engines or voice assistance and-and so on. I think we also know that in May of this year, it was around 67% of our users that were accessing GOV.UK on mobile. And we see that number increasing year on year. So the work that we've done so far is good. We're-we're responding to changes in user behaviour where possible. But this objective for this year is really about enabling that step change. So through coronavirus, all of our services were designed as mobile-first. But what we need to keep pace with technology. So this is thinking about exactly to your question, designing for provision for access to-to GOV.UK information and services beyond the website. And that's yeah, super exciting because I think it's-it's keeping it's keeping pace with the user needs and changing user behaviour. It highlights how the 5 objectives that we have for our roadmap for the year, they're not, there's a huge amount of interdependency there. Right. We started out with the fundamental building blocks of being available, accessible, accurate. We build on with like supporting priorities of the day. We talk about personalisation. We talk about being channel agnostic. You put all of that together and like holistically that is about GOV.UK and enabling users to access information about government and services in a way that is tailor, that is personalised, that suits their needs.  Ross Ferguson: GOV.UK's getting close to being one of the top five, most used to most visited sites in the, in the U.K., and it goes up that-that list every-every year. And so I think that people will always value there being a site that they can go to or certainly they will value that for-for many, many years yet. There have to be other other channels that you are able to benefit from the information and parts also the services that are on the GOV.UK platform. And because, again, you might not know that you you could benefit from that information and other services, other parties might usefully be able to suggest, OK, actually you need you need to know this from the government or actually at this stage in your transaction with us, actually government can is the best place to help you with this.    And so I think that we want to explore those and call them partnerships, those and those crossover's a bit a bit more. Yes with some big household name technology companies, but also with groups that are involved in civil society. And this could be a national, it could be at a local level as well, and they are providing great support and services to-to their and their constituents, their members, their-their users. So I think there's a lot that we can do there.    I think what cuts across all of these, whether you're using a voice assistant more, you're perhaps engaging with some citizens advice and service or information on BBC is that you want to know that that information from the government is-is-is quality, is reliable. And so I think that that's where the GOV.UK verification, the GOV.UK brand, if you like, can really, really be useful there. And that is new ground for us. It's exciting perhaps to be--have a presence off of our own domain. And, you know, you mentioned we've been talking about trust earlier on, whatever we do in this space has to be underpinned by trust. And to get that right, we'll do experimenting and we will, we will talk to users because that is what we've always done. And that will keep us right.   Vanessa Schneider: So before we start to wrap up, I was wondering, what are you most excited for on this journey? Let's start with Ross.   Ross Ferguson:  That's a tough, that's a tough question. I-I am excited to see what the, what the response to the account will be. I'll be interested to see the way when we--as we roll out across the whole of GOV.UK this year and how people will respond to that, whether they will see it as a good utility. I'm anticipating the feedback, anticipating it being positive. What-what I'm looking forward to most is, is the detail about what more it could do and about how it should interact with services. I think that will give us a lot to go on.   Vanessa Schneider: Thank you Ross. Same question to you, Rachel please.   Rachel Tsang:  I think for me this is going to sound incredibly broad, but I think it's the energy around the delivery that we're doing right now. Like, we've got a really clear vision and direction and we've blogged and can I say podcasted? We've podcasted about it. And I think having that honesty and clarity about what we're doing and being really open about it is super important. Right. And I think that buzz is we're-we're kind of generating that buzz out externally.   But it is also very, very much with the team that's delivering on GOV.UK. And that's super exciting. And-and we can, I--can I talk about recruitment? Because I know we're very, very, very keen for lots more people to join GOV.UK. And we've got super exciting vision. We've got a clear direction of travel. So we are recruiting lots and lots of different roles. So user researchers, data scientists, product delivery, design, technology. I would say, particularly in the technology space as we design the architecture we talked about we platforming earlier on and so worthwhile having a look at the GDS career site to see our live roles, have a look at the blog. Ross and I, we published a blog post on four tips for applying for a job on GOV.UK. And we're hiring with a particular focus on our Manchester hub. Indeed, both in--both Ross and I are based up North.   The only thing I would add with that: this is actually really exciting, I think this is important to both Ross and I is that we are investing in junior roles, right. We want to build our-our pipeline of talent and invest in the development of people. So I would say that this isn't just about recruiting at a senior level. We're looking at all sorts of roles and all sorts of levels. So please do come join us.   Vanessa Schneider:  Thank you to both of you for joining us today on the podcast, and thank you also to all of your colleagues who joined us to share their contributions to the GOV.UK Roadmap objectives.   As a reminder, we are currently recruiting across GDS, and quite extensively for the GOV.UK programme. So we invite you to look at our vacancies and apply if you’re interested in any of the opportunities.    You can listen to all the episodes of the Government Digital Service podcast on Apple Podcasts, Spotify and all other major podcast platforms. And the transcripts are available on PodBean.   Goodbye.   Rachel Tsang: Bye.   Ross Ferguson:  Thank you very much. Goodbye. 

Wondered how to migrate a 24/7 product to a serverless platform? We chat about initial user research, developing DevOps skills and the benefits of GDS's approach to this type of tech project.   --------- The transcript of the episode follows: Vanessa Schneider: Hello and welcome to the Government Digital Service podcast. My name is Vanessa Schneider and I am Senior Channels and Community Manager at GDS. Today, I am joined by Jonathan Harden, Senior Site Reliability Engineer, and Kat Stevens, Senior Developer and co-Tech Lead on GOV.UK Pay.   GDS has many products that rely on our expert site reliability engineers and their colleagues to maintain and improve their functionality. Such as GOV.UK Pay - one of GDS’s common platforms that is used by more than 200 organisations across the UK public sector to take and process online payments from service users. Jonathan and Kat recently completed a crucial reliability engineering project to ensure that GOV.UK Pay continues to operate at the highest standards and provide a reliable service for public sector users and their service users.    We'll hear more about that in a moment, but to start off, can you please introduce yourself to our listeners? Kat, would you mind starting?   Kat Stevens:  Hi I'm Kat Stevens, I’m a Senior Developer on GOV.UK Pay. I've been working at GDS since 2017. And before that, I was a developer at start-ups and small companies.   As a co-Tech Lead on the migration team then, I'm kind of jointly responsible for making sure that our platform is running as it should be. That our team is working well together, that we're working on the right things and that we're, what we're working on is of a high quality, and is delivering value for our users. So it's like balancing that up with software engineering, making sure that you know, that we're being compliant. It's very important for Pay.  Software [laughs] engineering is so broad: there's like security, reliability, performance, all of those things. So yeah, it's kind of thinking about everything and---at a high level.   Vanessa Schneider:  I'm glad somebody's got a high level overview. Thanks, Kat. Jonathan, would you mind introducing yourself too?   Jonathan Harden:  Hi, I'm Jonathan Harden, and I am Senior Site Reliability Engineer on GOV.UK Pay. I've previously worked for a major UK mobile network operator, in the movie industry and for one of the UK's highest rated ISPs.   So all of GOV.UK Pay's services run, have to run somewhere. Being a Site Reliability Engineer means that I'm helping to build the infrastructure on which it runs, ensure that it is operating correctly and that we keep users’ cardholder data safe and help the developers ease their development lifecycle into getting updates and changes out into the world.   Vanessa Schneider:  Hmm..exciting work. So you both worked on a site reliability project for GOV.UK Pay. Can you please, for the uninitiated, introduce our listeners to the project that you carried out?   Kat Stevens:  Yeah so recently, we finished migrating GOV.UK Pay to run on AWS Fargate. So previously Pay was running its applications on ECS EC2 instances on AWS. That's a lot of acronyms. But it basically means we were maintaining long-lived EC2 instances that were running our applications. And that incurred quite a high maintenance burden for the developers on our team. And we decided that we wanted to move to a serverless platform to kind of reduce that maintenance burden. And after researching a few options, we decided that Fargate was a good fit for Pay, and we spent a few months carefully moving our apps across to the Fargate platform whilst not having any downtime for our users, which is obviously quite important. Like Pay is a 24/7 service, so we wanted to make sure that our end users had no idea that this was happening.   Vanessa Schneider:  Jonathan, how did you contribute to this migration?   Jonathan Harden:  So obviously, I've only been here for three months, so and the project has been going on quite a lot longer than that. But this is the kind of task I've been involved with, uh, several times now in the last few years at different companies. And so when I joined GDS, it was suggested that I join this project on Pay because I'd be able to contribute really quickly and, and help with the kind of the, the long tail of this migration.   So a-anybody else that's been in an SR- that works in SRE capacity will know that when you do these kind of projects, you have like the bulk of the migration where you move your applications, like your frontend services that users actually see when they go to the website and the backend services that processes transactions. But then you also have a lot of supporting services around that. So you have services like: things that provide monitoring and alerting, infrastructure that provides where, where do these applications get stored when they're not in use and like where do you launch them from. And there was, there was still quite a bit of that to tie up at the end. And the team, it's quite a small team. As a lot of SRE and infrastructure teams do tend to be. And so when I started, I joined that team and I've been helping with the, the, these long tail parts of the migration. Like in a lot of software engineering, the bulk of the work is done very quickly and the long tail takes quite a bit of time. So, so that's the kind of work that I've been helping with in the last few months.   Vanessa Schneider:  Great. Kat, as co-Tech Lead, what was your involvement in the migration?   Kat Stevens:  Let’s see where to start. So when I joined the Pay Team, which was around October  2020, we were in the early stages of the, of the project, so we'd made the decision that we needed to migrate and that involved things like analysing, like co-cost benefit things. I-It doesn't sound that exciting, but it was actually quite cool looking at all the different options. So, for example, it meant that we could keep some of our existing infrastructure. We wouldn't have to move our RDS instances for, for example. We could keep our existing security group, subnets - all that kind of glue that holds all the application, like infrastructure together.    Then there was quite a lot of planning of how we would actually do this, how we would roll out the migration application by application. We've got around a dozen microservices that we were going to move one by one. And figuring out what good looked like. How would we know that the migration is successful. How do we know whether to roll back a particular app.   So for the actual rollout of migrating sort of one application from EC2 to Fargate: we basically did DNS weighting. So we could have both run--versions of the app running alongside each other, and then you can have 5% of the traffic going to new apps, 95% to the old app. And you can gradually switch over that weighting and monitor whether there are any errors, whether like the traffic suddenly dips and things aren't getting through. So that was all part of the plannings. Like what, what stages would we reach to say like, that yes, we're confident that this change has been positive. And like having a whole, like overview view of what's happening when. Estimating things as well - that's alway, always pretty, [laughs] pretty difficult. But we, as the more apps we did, the quicker we went and we sped up on that. So that was good.   And yeah, there's a whole bunch of other things we, we had to get involved with over the last few months as well. So that's things like performance-testing the whole environment to, you know, we wanted to have confidence that the new platform would be able to handle like the high levels of traffic that we see on GOV.UK Pay. Also we wanted to look at how we would actually deploy these apps. Having more confidence in our deployments, moving to continuous deployment where possible. So while those things weren't like directly impacted by Fargate, doing this migration like gave us the opportunity to explore some of those other improvements that we could make. And yeah, I think we've really benefited.   Vanessa Schneider:  That makes sense, it's always nice to not just keep things ticking over, but making big improvements, that feels really rewarding, I think. Can you give us an impression of what the situation was before the migration maybe?   Kat Stevens:  On our previous infrastructure, we were running ECS tasks on EC2 launch types - so those are sort of, relatively long-lived instances that we had to provision, patch, maintain. And the developers on the, on the rest of the team, and I--we're not necessarily infrastructure specialists, but when developers on our support rota would end up spending sort of like maybe 5, 6, 7 hours a week just maintaining our EC2 instances, we kind of realised that something had to change [laughs]. And use it, moving to a serverless infrastructure, it's just completely removes that burden of having to provision and make, roll our AMIs, our machine images. We, that just doesn't happen anymore. And we've freed up our developers to work on features. And yeah, the, the infrastructure burden on Pay is just so much less.   Vanessa Schneider:  Oh, that sounds really helpful. I’m not sure if migrations are an every-day kind of job for site reliability engineers or software developers, so I was wondering if there’s anything that stood out about this process, like an opportunity to use new tools, or a different way of working?   Jonathan Harden:  So yeah, it's fun to work with new tools. But there, there, you get to--part of working here, and something I've seen in the time I've been here already, is that we don't rush into those decisions. So it's perfectly possible to see the, the new hot thing in the industry and rush straight for that without a good understanding of what are the trade-offs here. Everything has some trade-offs. And here at GDS, what I've found personally is that we put a lot of effort into understanding what, what's involved in the change; what will the experience be like for - I mean, the customer experience, the user experience, people actually paying for services, that needs to remain rock solid the whole time - but what's the, what's the experience like for developers? So developers have a cycle. They, you know, they write code, they want to test that code somewhere, they want to get it approved and push it to production. And, and so right now, we're undergoing a process of replacing some of our deployment pipelines. And as part of that, we're, we're in the early stages of this, but we're doing real research into how will our change of that be for the developers. And there's something really, really, really rewarding about looking at the different options available, seeing what is the new, the newest cool things, are they where to go? Do you want to go to something a bit, a bit older and a bit more stable? Is there a happy medium? What will the experience for developers be like there? What will the maintenance burden be like?   And one of the things for me here is that I'm seeing that e-even down in the teams, it's, these decisions aren't being taken by somebody higher up saying: 'we're going to move to this thing, make it happen'. And instead we've, we're doing research down in the teams that are going to do the work, speaking to the developer-- we're going to be speaking to the developers and surveying all the developers about what do you want from not just the change to stay the same, but change to make an improvement. And it's really, it's exciting to work with the new tools and the new possibilities, and it's also exciting to be involved in making those decisions.   It marks quite, it was quite stark for me when I first started and I was told this, this major project is going on and it's likely to be 3 to 6 months before we start work, start work on doing it because we're doing the research up front and it's happening in the teams. People are spiking on cool things. Which means even if it's technology that you don't get to use eventually, or that you choose - not don't get to, but choose not to use eventually, you know, the teams are helping to make this choice. You get to try out a bunch of different technologies. And one of the great things with that at GDS is: there are different parts of GDS, and different parts of GDS are using the tooling that is suitable for their area, that makes their area best, work best. And that does mean that there's scope for if you decide I want to work on this other cool thing and this other team are working on it, you can move into one of the other teams and work on that new cool technology.   Kat Stevens:  I mean, I-I-I agree totally. I mean, one of the reasons I wanted to move to Pay was to get more experience working on the infrastructure side of things. On a previous teams it was more sort of stuff like cool software engineering. And on Pay, I've learnt more Terraform than I [laughs] ever thought was possible to know. And loads of other skills like: I've got so familiar with like all the, the intricacies of it as well. And kind of like sort of pushing it to its limits almost, and trying to get the best out of the tools for our, for our team and for our projects. And yeah, it's, it's, it's been really exciting. I mean, one of the new shiny tools that we've been looking at was cloud watch, and we use it for running our smoke tests now. And that was part of the, we kind of like rolled that into the, the Fargate migration project because it seems like a good way of us, like checking that our deployments were working correctly. It took a little bit of wrangling for it to get, fit that into our deployment pipeline. But, but it is really cool sort of like seeing the new thing just falling into place. And now it looks like some of the other teams are following us and using that, that tool as well. So it feels, it feels [laughs] quite nice to be a trailblazer.   Vanessa Schneider:  No pressure to get it right then [laughs]. What were some of the things on your mind when you were making those selections then?   Kat Stevens:  We wanted to make sure that we'd made the right decision. So we did spend a fair amount of time actually analysing all the options. In the end, we, we went with Fargate, purely because it meant that we could reuse some of our existing infrastructure.   Overall we kind of prioritised what was going to be the lowest risk in terms of how we were going to do the migration. Like would any sort of mi--you know, would we need any downtime; would this impact like our, our paying users; would it impact on like our service teams, the actual sort of government departments who use Pay; would it im-impact other developers who were actually trying to build new features. And if they've got a platform that's shifting underneath them, that's always going to be difficult. So we were really trying to go for an option that met our needs and like achieved our goals of reducing maintenance burden, saving costs as well, obviously. And yeah, [laughs] just making it, making like Pay an easy, you know, simpler and easier to be a developer on. And weighing that up with, you know, what, what's this like you know, new and shiny thing, like what's all this. Like you know, because there's so many tools out there. But if it's going to take us like a huge amount of effort to actually migrate to them, then I--is that benefit actually going to pay for itself or not? So we, we actually did quite a lot of the investigation analysis, a big spreadsheet [laughs] trying to calculate how much like developer time like in hours per week of what's being spent on infrastructure maintenance and kind of trying to estimate what-- how that would change when we moved.   Vanessa Schneider:  Cool, that sounds like the bigger picture view the co-Tech Lead would have of course. Jonathan, any, any benefits that stood out to you perhaps?   Jonathan Harden:  The, the process of trying these things is really interesting. One of the things that we do at GDS that is not something I've ever experienced elsewhere, I know it does happen elsewhere in the industry, but is, we have what I call firebreaks. So they're a gap between quarters. Now when I say quarters, we're not like planning so these 12 things will happen in the quarter. We are, like our team is running a full Kanban approach because we're an infrastructure team that do some support. And one of the things with those firebreaks is they're a week long. So I've worked lots of places where you do hack days and hack days are great but one day isn't really very much time to truly try something deeply. On the firebreak, you get the opportunity to work, to try something that might-- you know something's coming up. You know you're going to do this migration. You've got some thoughts about, 'ooh, there's this technology. I've heard it's great. I can give it a real try and I can prove to other people that this is something we should seriously consider, especially if it's really exciting for you'. Or you might use the opportunity as well to, to scratch an itch that's been bugging you.   So like I-I- just to give you an example of what: we've just had a firebreak. And during that firebreak, we saw several different versions of Terraform. For people that know Terraform, some of them were the versions that use the older version of the language - so HTL1 - and some of them with the version that used HTL2, and it means they're not very compatible. So I used that firebreak as an opportunity to upgrade all of our Terraform to get everything up to the very latest. And like that's really scratched an itch for me. And that's not necessarily super exciting for everybody, but for people that have to work on this day to day, it is very, very, very [laughs] exciting. And, but other people did spikes on trying out a whole deploy-- new type of deployment, which is part of what we're doing going forward. And I'm seeing across the other teams, the developer teams, people trying spikes from potential product features, it's very exciting to see those things happening in other teams and people really trying out, and not just a quick hack, but like really trying: 'can we get somewhere with this, and what's the opportunity for using this in the future?' And it's what people wanted to work on. And that's really, really, that was really exciting for me as, as a part of the research, like the ongoing research, the fact that they happen every quarter. It's very exciting.   Vanessa Schneider:  Kat, firebreaks - what’s your opinion, are you a fan?   Kat Stevens: Obviously at GDS like our quarters like, you know, we do carry over work between quarters, but it is nice to have that, that week or so where you can just like think about something else. You can, it's, you can recharge, you can reset little bit, you can try something new. And having like the, like the support from senior management to do that as well and have that space to experiment and try out new things to fail as well, I think that's so important. And even if your product like, never makes it outside a firebreak, you can, it will stick in your memory. And so when 6 months later they say, 'oh, maybe we should try this' and you can actually say: 'that might be a disaster. I remember it from my firebreak' [laughs]. Or you've got that background knowledge to just give context on a wider discussion, perhaps. I think it's so useful.    And also it kind of gives you an opportunity to potentially collaborate with people who y-you don't normally work with or with people in different roles as well. So rather than just us working within the migration team or the feature teams, we can kind of chop and change. You can work with like User Researchers or Content Designers and do just the things you wouldn't normally do. And or even if you just need a little bit of time to do some housekeeping or tidy ups and stuff that's, like Jonathan said, is just scratching that itch. So I love, I love a firebreak.   Vanessa Schneider:  It sounds like the firebreaks have been really productive then - are there any other wins you can share from the migration as well perhaps?   Jonathan Harden:  One of the interesting things, for me one of the interesting things about working in Pay specifically in GDS, is that we have to maintain PCI compliance because we're taking payments. Now that's not something I'd ever done before coming into Pay. So the, the first thing I did in Pay was learn about PCI and spend some time learning about what it, what it means to be compliant. But part of that is called protective monitoring. So you have active scanning going on looking for 'is anything nefarious happening over here, has anything goes wrong over there'. And that means that you, people have to spend time responding to those reports. And those reports, you occasionally get a false positive. But spending all that time dealing with those reports and investigating them like that's, that's all been freed up now.   But that means we can focus on future improvements more. So we've, our, we have a new environment to test performance of the application in. W e're going through a process at the moment of making it so that that environment can appear when it needs to appear and go away when it doesn't need to be there. And that, of course means saving money, which you know, we work in the Civil Service, this is taxpayer money. This isn't like venture capital, it's the money that all of us pay in tax. And so it's like even more important to make sure that we're spending the right money. It's not to not spend money, it's to spend the right money and only the money that you need to spend. And so we're able to spend time making sure that we can have that environment scale itself down and scale itself back up and use that learning of scaling up and down those environments to start working on potentially auto-scaling the other environments so that they respond to meet demand instead of needing to be at the capacity for peak demand all the time.   This is, the-these are quite exciting things in themselves, but like we wouldn't have, we wouldn't necessarily have the time to do these smaller improvements that, you know, that will save money. They'll make a big difference in how much we spend.   Vanessa Schneider: What about you Kat, any thoughts?   Kat Stevens:  Yeah, so previously while the majority of our apps were running as tasks on EC2 instances, we did have a couple of Fargate apps running. And people were a bit nervous about updating them and deploying them. But now we are deploying to Fargate everywhere, suddenly, it doesn't seem so much of a big deal anymore. And so we've been able to kind of demystify some of those extra auxiliary apps. We've had really good feedback from the developer team saying like: 'this is great. We don't even have to, you know have like a, mental energy spent on worrying about this app anymore'. And that's kind of like the same for our other sort of, the, the bits and pieces that go under the radar. So this is something we're kind of looking at now is: how do we make sure our NginX proxies are patched and up to date and get deployed quickly, and it's not going to be a, a huge mental effort even [laughs] to kind of even think about how do we do this: 'we don't do this very often. Am I going to have to look this up again?' We can automate more of these processes and just have a more stable and reliable platform.   Vanessa Schneider:  It can be intimidating when you don’t do a process frequently, just wanting to make sure you get everything exactly right, I think a lot of people can relate to that, but it’s so good [laughs] everyone’s confident now!   Kat Stevens:  Big factor but yes.   Vanessa Schneider:  So, obviously, Kat, you aren't a Site Reliability Engineer, but working on this project has given you the opportunity to upskill in the area. Is that right? Is that a common practise? Is it, is it normal for Software Developers to sort of take on a project like this to learn these things?    Kat Stevens:  It's interesting. I think the role of a Software Developer at GDS, it can be so broad. And there's so many different types of things you can work on. I was working on Python projects for a couple of years. And I've sort of like, dipping my toes into a bit of Ruby and bit of JavaScript. And...but, but the previous team I was working on, the infrastructure was very stable and there, there wasn't really any, a huge need to like revamp it or do any major bits of work on it. So while there was a couple of bits and pieces ad-hoc here and there, it kind of felt like the, the infrastructure side of the whole software engineering ecosystem, [laughs] for want of a better word, the, the, the infrastructure side of it was, was a gap in my knowledge. And so it's been really good to be able to move to Pay and like roll up my sleeves and get stuck in and you know like, figure out all these IAM permissions, what, what needs to be done where and actually sort of like get, getting that experience in like lifting the hood and seeing what's powering the, the actual software underneath. And almost like going down through the layers and yeah, [laughs] it's been, it's been really eye-opening actually. Like...previously, I would have never described myself as doing any sort of DevOps side of things, and I was actually quite like scared of Bash scripts. And now they are, yeah, well, I wouldn't say second nature, but they're not so scary anymore [laughs].   Vanessa Schneider:  That's a great outcome in my books. Jonathan, is it common practise to have somebody come in like that for you? I mean, obviously you've not been at GDS for a long time, but I was just wondering how this compares to the private sector.   Jonathan Harden:  So lots of people want to be a Site Reliability Engineer, it's a very kind of hot field. It's a very cool area to work in. And I don't just mean across the industry. I mean, I think that's a, I really, really like this role. I've put on many hats over my career and this is the one I'm enjoying the most by a long way. But, so in a previous company, I was like leading a team of infras-- there we were calling ourselves Infrastructure Engineers, but we were hiring Site Reliability Engineers. And actually, we found that it, it was, in some ways it was better to have a more diverse team in previous role as well. I mean, like, I always believe it's better to have a diverse team anyway in all aspects. But having people from a software engineering background and people from a systems administration background, like a traditional SysAdmin background, bringing those people together, especially if you've got one or two experienced Site Reliability Engineers already, works really, really well. People want to upskill into this area. Upskill isn't even necessarily the right word. People want to move into this area. It's not that it's an upskill, it's, it's, it's sideways. It's a different kind of role. And it means that they're very enthusiastic and they really want to learn these things and they want to demystify the scary things like Kat was talking about. So me personally, I've been, she mentioned Bash, I've been using Bash for many, many, many years [laughs] since about 2001, I think something like that. So that's not scary for me, but for people who haven't worked with it, I can help them with, like you know, I can help people and I can mentor them and I can show them good practises are.   Vanessa Schneider:  I don't think I've heard a better recommendation for folks to become site reliability engineers - keep an eye out on our vacancies as there are continuously opportunities at GDS to work on exciting projects like this migration, or broaden your skill sets. But just to recap, would you say there’s anything you’re particularly proud of as a result of this migration?   Kat Stevens:  The--like the actual how we did the rollout itself like with zero downtime. I thought that was pretty cool. But also maybe kind of like in the ways that we actually worked as a team around it as well because it was quite a long running project. And I think there's some interesting parts about how we like re-reassured ourselves that we were doing the right thing. Like, you know, regular retrospectives, firebreaks like we've mentioned, like how we dealt with unexpected work coming along because [laughs] as well as being like the migration team, we are also kind of the infrastructure team. So any kind of unexpected bits and pieces that came up, it would be our team that, we would have to like temporarily pause the migration work and pick up you know, whatever it was. So how we responded to that and you know how we communicated with each other, I-I think that's kind of a whole, a whole other podcast in itself almost.   Vanessa Schneider:  It sounds like there is an amazing community that you can tap into to keep up to date, make sure that work isn't being duplicated. And clearly there’s a lot to be proud of regarding the product performance.    Jonathan Harden:  Yeah, so something that I found a little different here from other places I've worked, even larger organisations, that actually really helps with the sharing of information: so we, we have various like show and tell type catch-up meetings but for a wider than just your small area of the, of the business. So we have a catch up every week amongst all the infrastructure people. And there we all talk about what are we working on right now; like what things are we looking at in the future; are there challenges that you faced; how is the business as usual stuff going in your area. And conversations often come out of that into: 'oh, you're trying out this new technology?' Or you might, because we have it every week, you might mention like: 'oh we're starting to look at this thing' and you'll hear other people's opinions on either the thing you're trying or what you're aiming at or what they've done.   So we, I was mentioning we're doing this tuning our deployment pipelines, so we have a-a few peo-teams are all doing that as well. And so we have a channel where we're talking about that. And as people are trying things, they're putting in that channel like what they're trying, how it's going, like what the challenges they faced are and, you know, asking for help as well: have other people tried this; what, did you manage to solve this issue or that issue. And I really feel like the collaboration across parts of GDS and the wider Cabinet Office is, is really, really good. within the infrastructure side, it's really good. There's definitely like beyond the infrastructure I do attend, we do have show and tells where people get to show like the thing they're working on that's not just infrastructure related, and that's been, that's really good as well for just understanding like the wider landscape of what's happening across Cabinet Office. And that's that's really, they're really helpful to communicate those things and to work out: 'are we working on the same thing'; 'are you about to start working on the thing that I'm working on'; 'have you already done this and can you give me some pointers'. And that's really good.   Vanessa Schneider:  Yeah, it’s nice that you've had the opportunity to share your learnings with the community. Do you have any, maybe, more personal reflections on this work perhaps?   Jonathan Harden:  Yeah. So working at the Cabinet Office, it's the first time I've worked for the Civil Service and I'm very aware it's, it's different than the other roles that I've had because I'm like, I feel like I'm kind of helping wider society. We all have to pay the government for all sorts of things. And Pay supports many different services, including - on a previous version of the GDS podcast, you talk to some of the product people from Pay, and I listened to that before I joined Pay, before I joined GDS, and it was really interesting to hear the esoteric services that we have - but of course we have some, we have some bigger services as well and other government departments coming online all the time. And knowing that the infrastructure we're working on supports the ability for the public to pay things that they need to pay to the government or they want to pay, you know, they, like you said, they might be buying a fishing licence or something like that. And that's, knowing that we make it easier for people to do that and that it's done in a way that focuses on the accessibility of the service so any member of the public can try and pay through us and will have, not reach barriers like their screen reader software can't work with the service.    These are, knowing that I'm giving this back as part of my role, it makes a big difference to me as an Engineer. It's, it's, it's kind of the first, one of the first times where I've not have some kind of crisis around like, 'oh, am I giving back to society, wider society?'. And now I really feel like I am. And that's a real big part of what's making me so happy here among working on a fantastic team and a great org, and on cool technology, of course.   Vanessa Schneider:  That's so lovely to hear, Jonathan, [laughs] thank you for sharing. If you are similarly minded and want to try and help wider society, do keep an eye on our careers page. That's: GDS careers dot gov dot uk [gdscareer.gov.uk] for openings. It could be in site reliability engineering, it could be general software developer, it could be very different, but we're always looking for new folks to join us and bring their perspective into the organisation.    Thank you to Jonathan and Kat for joining me on the episode. If you like it, you can listen to all other episodes of the Government Digital Service Podcast, like Jonathan has, on Spotify, Apple Podcasts and all other major podcast platforms, and the transcripts are also available on PodBean.    Goodbye.   Jonathan Harden:  Toodelo.   Kat Stevens:  Goodbye!