Government Digital Service Podcast

Why build a product people won't or can't use? Our user researchers share their approach to understanding needs for government’s single sign-on. ---------   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. In August, we recorded an episode on digital identity and single sign-on as part of our plans to develop one inclusive and accessible way for people to log in to all government services online. You heard from Will and Helena from GDS, as well as Tom from Veterans UK, who shared how we worked with other parts of government to shape this work. Since then, we passed the digital identity service assessment, integrated our authentication component with the first service, and completed research with more than 800 end users. And it's that research that we want to talk about today. Joining me in this are Lauren Gorton and Charlotte Crossland, both user researchers at GDS in the Digital Identity Programme. Lauren, could you please kick us off by introducing yourself and what you do? Lauren Gorton: So I'm Lauren. I'm a user researcher on the digital identity programme in GDS, and specifically I work in the authentication team. We look at the credentials that people use as part of the single sign-on. And the first steps of our journey went live in October. So specifically, I focus on the end user aspect of that and focus on the citizen side. Vanessa Schneider: Fantastic, thanks. Charlotte, could you please introduce yourself and what you do as well? Charlotte Crossland: Absolutely. Hi, everyone. I'm Charlotte, I'm a user researcher on the digital identity programme, working in the design for adoption team. We've been doing a lot of research with service teams across government. We're building an authentication onboarding journey, as well as looking at identity materials that teams can use to make decisions. Vanessa Schneider: Fantastic, thank you so much, both. So, not everyone will have listened to the previous podcast episode or read the blog posts that we've written about this work. Would one of you mind explaining a bit more about One Login for Government? Lauren Gorton: Yes, so One Login for Government is one of the government's major projects at the moment. On GOV.UK there, there are several different sign-ins at the moment, and many different routes users could take. So what we're trying to do is streamline that down, so that in the future, there'll just be one single sign-on for GOV.UK to help improve the journeys for users and reduce confusion for people. That then opens the door to do lots of other cool things in the account space, so that people aren't having to repeat themselves too often in different services, and it helps government to basically join up a bit better. Vanessa Schneider: Great stuff. I can see the importance in that [laughs]. Obviously, this is a loaded question to ask, given both your roles as user researchers. But I was wondering why is user research so integral to that? Lauren Gorton: So there's no point in building something if people won't or can't use it. And the only way we know if we're on the right track is if we actually speak to the people who are the intended users. That's probably important for any organisation or business, but it's especially important in the context of government, given how important government services are if people can't access them, that can have a huge impact on people's lives. So we can't really afford to build something which people either can't use or won't use. [For] the citizen side of the research, our approach is to gather insights at all stages of the projects and from as representative a sample of people as possible. One thing is that we're not reinventing the wheel. There have been other government projects that have come before us who've done work on sign-on services. So there's a lot of existing research and insights that we can sort of learn from as a first step. So we, we initially did some very extensive desk research, including research artefacts from Verify, Government Gateway, recent COVID[-19, coronavirus] projects, and, you know, getting lessons learnt from peers in the NHS, who are working on the NHS login at the moment as well. So it's kind of given us a running start, really, to see what worked well before us and what didn't work so well. And we then built on top of that with our own research. So for a variety of different techniques, things like doing interviews with people and conducting surveys, testing our journeys as we develop them and iterating them. And since May, despite the impacts of COVID and issues that we had with research - we obviously haven't been able to go out and actually talk to people face-to-face, we've had to adjust how we work and do everything remotely - but despite that, yeah, we've managed to speak to over 800 end users, as you mentioned, since May. On top of that, it is really important to call out that once something's live, it's not live and then done, so now that we're live with the first steps of authentication, we've also got thousands of users who are now going through the live service and we're getting insights from those people as well. So relying a lot on our feedback form and also the analytics that runs for our service to better understand, "OK, so these are real people, using it in a real-life scenario: how is it working for them, and working, we keep improving it." So it's kind of that balance of we're doing a lot of the research with people to help prep them, optimise before we go live. And then as it's live, we're still monitoring it and trying to improve. Vanessa Schneider: Well, there's a lot of work going into it, I can see, and it's really heartening to hear that you're taking on the lessons from the past. And actually, that probably relates to the work that we're doing with other departments because they have existing identity solutions, don't they, Charlotte? Charlotte Crossland: Yeah, absolutely. So our approach from gathering insights from service teams in government has been a bit different from doing research with end users - it's a bit of a different dynamic. The real key to this is collaboration. So like other government platform products our users are peers working across government. I've been working with a range of roles, from product people to service owners, researchers, designers, developers, even data [analysts], both across central and local government. And it's been really fundamental to tap into, again, the existing work that's there; digital identity is a well-trodden area across government. It's a fundamental, it's been creating a space of trust and being as open as possible with teams and departments. It's important that we take aspects of that into our approach, not only internally within the programme, but taking that approach externally across government. Yeah, if the whole team is supporting and involved in that session, we have the capabilities and materials to produce really rich, UR [user research], building up that trust and developing relationships is far more important because they're the teams that are building and developing the services themselves in their everyday lives. Vanessa Schneider: Obviously service teams will have also conducted user research for their services with end users. How did that integrate into sort of your knowledge base? Lauren Gorton: Yes, so that was a part of the desk research that we did, kind of, in Discovery Alpha. We went through hundreds of different documents to, to try and understand that. But, as well, we've also since had sessions with teams so, the basic digital service, so they have a really good component for certain aspects of the authentication journey. So we're trying to make sure, again, we're not reinventing the wheel. So if things have worked for, for their end users, it's going to work for [our] end users as well. So we've been, we've met with them, tried to understand the component, looked at some of the data behind it and have applied that, aspects of that, to our own journeys as well. Vanessa Schneider: Neat, and obviously, this could be really interesting for folks, depending on how long we're going to be in these unprecedented times or with the future of work being maybe more remote working: How was it conducting user research while maybe not having direct access to people? Lauren Gorton: Good question. So, yeah, that's, that's been difficult. I think it was definitely for user researchers, just in general. It's hard if, you know, you're not in the room with them. And something that user research just needs well to do is to have, like, a good rapport with the participants. And it can be hard to try and build that up remotely and so, you know, reassure people and calm them down remotely over a video call. So, yeah, there are different frustrations to it, particularly if someone runs into an issue in the middle of a session. We can see the screen and what they're doing. But if they go onto a different device because they want to search something on the mobile phone, we can't see what they're doing and we can't help them, so that's caused challenges as well. So it's been a big challenge for communication, I think. But there are, there are positives to it as well. It's quite nice to have a video call with someone, they dial in, you run the session, if it goes well, and then you can just dial off, that's the session done. You can go, go grab a coffee, [laughs] to then try and absorb what you've just learnt. So yeah, there are nice things to it as well. Charlotte Crossland: Yeah, definitely echo Lauren's point around that interaction, and no matter who you're researching with, whether it's citizens or service teams. It's really difficult to get that rapport up online compared to in-person, where you can read people's body language, their tone, it's a very different dynamic. And I think what's I've learnt the most about doing research with service teams is that they are our peers and, as we've mentioned before, digital identity is a well-trodden area, and it's about collaboration as much as it is user research with those power dynamics that are often associated with it. I think as well, on the analysis side, so we're really fortunate to have tools that really help bridge those gaps from doing analysis in-person to remote ways. They've yeah, they've been so valuable. Lauren Gorton: Charlotte's raised a really good point there as well, which I totally missed, but afterwards with our colleagues when we're trying to, like, go through what we've learnt in the session. That's been super hard as well because we're not all just sat around the table together with notes and writing on a whiteboard. So yeah, that's been a real struggle as well. Vanessa Schneider: I think that a lot of listeners can relate to the difficulties that you face, the challenges that have presented themselves. But it is nice to know that there are some things that have helped or some things that are manageable at least, despite the circumstances. So that's really encouraging. So it's great to see that we've got these partnerships going with other departments. How do these partnerships come about and why is that so important to us? Charlotte Crossland: Great question. So we're collaborating at multiple levels in government departments, so recently colleagues have kicked off strategic department-level work with the big departments and these will continue to be expanded on. We're also working directly with services at service team-level, as well as clusters of services, to give us a really wide and deep view of requirements. So we've been building on from the robust thinking that– of digital identity that already exists within government. The collaboration has shaped the programme thinking, so the development of the roadmap, the functionality requirements, to prioritise in specific work, such as exploring low levels of confidence, which our team is currently looking at. So, as mentioned before, in the previous Digital Identity podcast, as well as collaborating externally, we need to reflect internally and learn from Verify. So to do this, we're ensuring inclusivity is at the core of what we're doing. We're not using third-party or private sector identity providers to verify users' identity. We're not taking a one-size-fits-all approach. We're designing for the needs of service teams, so doing research with service teams has really sought to address these last two points. I think one of the key collaborations, for example, the one with DfE [Department for Education] has come about through one of our key findings, actually, so this is around cluster services. So end users of cluster services are likely to see the benefits of a reusable set of credentials more readily as they're able to use the same authentication username and password to access them. So we've spotted clusters in well-known departments like HMRC [HM Revenue & Customs] or the Home Office initially, but we've also found clusters in all sorts of places across government. So users of Companies House, [HM] Land Registry, farmers using Defra [Department for Environment, Food and Rural Affairs] services, drivers using DVLA [Driver and Vehicle Licensing Agency] services, as well as teachers or students using DfE services. Lauren Gorton: Yes, so with our end user research, we've always been researching around the single sign-on and how that benefits our users. The single sign-on is the solution that we feel best helps to meet other user needs we found in research. But to do so in a way that also meets people's expectations and fits mental models as to how people look at government. So in terms of user needs, like, at its simplest level, our users need to be able to access government services, they come to GOV.UK with a task in mind, and that's kind of what they care about doing [laughs] and all they care about doing. They need to be able to do that without having to understand all the complexities of government and have to try to unpick that. So a user shouldn't have to land on the GOV.UK home page and say, "OK, today I'm trying to do this task. This service owns that task. This service sits in this department and that department uses this sign-in. So I need to go over there and specifically it's these credentials I have to use if I can remember what that-- what those credentials are". So, you know, users shouldn't have to do that. And it's not just the case, you shouldn't have to do it, but it also doesn't fit into how they look at government. So we found in our research, and this is general, because mental models, are general, not everyone thinks this way, but a lot of people, sort of, look at government and they see it as a single entity. We talk about "the" government and, you know, that, that's how people see it. They don't think about all the complexities behind it. And as part of that, we have heard people in research sessions and participants saying, you know, "I expect to just have the one account because I'm dealing with the government. I need a government account to talk to the government". So that's what we've, sort of, had coming out of our research sessions. And whilst we've heard that in research sessions prior to going live, again, since going live, we've also seen some data that also supports this too. So for instance, we have our feedback form, which people using the live service can come to. One of our most common themes in our feedback form is one we call "queries outside of our scope". And that's just basically for anything that's actually to do with a different service. So what we are seeing is a lot of people hitting our journey, going into our feedback forms, and they're leaving this feedback about different services or they're saying, "I can't sign in" and, you know, when we go back to them, we unpick it, it's because they're trying to sign in into, like, a Gateway or a Verify [account], because they want to do something with their tax, for instance, they've, they've come to us in error. So we are seeing in live that this confusion is a problem. It's the same with our analytics as well. We're seeing people coming to our journey, trying to sign in and having to go down those unhappy path routes because they're confused about whether or not they do have an account. And it's one of those things from a user perspective, that so long as there are multiple accounts out there, that confusion will exist to an extent. There's only so much we can do with research and design. So the more services we get onboarded and the more we reduce the number of sign ins, it's kind of the only way to really completely get rid of that confusion for people. Charlotte Crossland: Definitely, teams that have Sign-in already have seen account confusion from end users, it's a very well-known problem. I think, similarly to Lauren's point around service teams, so authentication and digital identity isn't a straightforward team need. So teams often integrate with identity as part of bigger changes and plans they're going through within their delivery cycle, but related to that. So checking people's identity documents is a really onerous process for service teams and government. It's really costly. Identity checks might not be up to scratch, so ultimately online identity checks could save teams a lot of time and money. It's also important to add to that, the offline routes will always be fundamental, so users and service teams will always need offline routes. Vanessa Schneider: Yeah, definitely important to stress we're not taking anything away from folks. We're just trying to make it easier. We're trying to make it, one, single safe, reliable, fast and effective way for everyone to log in to government services online. That's the mission. So earlier you mentioned trust, and then you also talked about how our new solution isn't going to use third-party providers to verify people's identities. Is that linked? Charlotte Crossland: Yeah, so on the identity side, our research has been really addressing exploring service team mental models around digital identity. So really digging into how teams feel and talk about identity, understanding the types of language that they use. Equally, we've been understanding how services decide on the level of confidence of an identity check. So who's involved in that decision-making process? What are the roles and teams in the department that are integral to this? And I think there's a really interesting design challenge of how we can effectively communicate how teams go about choosing an appropriate level of confidence that maps back to GPG 45, or the Good Practice Guide. There's a lot of evidence that shows GPG 45 doesn't equip teams to understand what identity profile or level of confidence is most appropriate. The guidance doesn't explain how this choice will affect a services' end user journey. That wasn't the aim of the guidance, but equally, the level of confidence the service chooses should be informed by the service's risk appetite. Vanessa Schneider: You did talk about your research reveals there are clusters, for instance, in different departments. Are we working with all of them? If not, why should departments be working with us? Charlotte Crossland: So it's really that sharing of knowledge and insights and that collaboration that can make digital identity a possibility in government, so teams, practical things that teams can expect from the partnership is like access to the technical documentation that we've been testing, so they've really got to shape what that looks like, they've been able to play around with it. How does that work in their integration environment? It's been really insightful for both parties involved. Vanessa Schneider: Well, in that case, I really hope more teams will register their interest in the private beta. As after all, as you said, you know, earlier adopters will reap greater rewards in the situation, really shaping what gets done. So Lauren, I know on your side specifically, there was quite an innovative approach with respect to how we use user insight to provide a full picture of the complexities of user lives. Can you explain a little bit more about what that involved? Lauren Gorton: So that was from our Alpha assessment. So, so during Alpha, rather than using personas, which are the traditional way to basically group your users, we used mindsets instead. So the difference really is that, whilst both tools are used to group your users, you can't focus, unfortunately, on everyone individually, we need a way to, to group our users so that we can see the different types of people using the service, and we can include those in the design process and refer back to it. Personas do that by quite heavily focussing on demographics. So you might create personas where you're having different age ranges from your users represented, represented, different ethnicities, gender - even things like do they have an access need? And then what you do on top of that is say, "OK, so what goals will these different types of users have when they're trying to use a product or service?" So that's how personas work with that very heavy demographic influence. Mindsets are different in that we don't think about demographics at all. Instead, we're trying to group our users based on shared behaviours and attitudes in a, in a particular situation. So mindsets focus much more on the different ways people might behave and the reasons which are driving those behaviours. So sometimes personas are the right tool to use, but there is a risk of things like stereotyping and subconscious bias. And to be honest, just in our, in our context, because our users are everyone in the UK plus international people it is kind of hard to use personas because we'd have to make tens of personas to try and represent that, which just wouldn't be manageable or usable. So we needed a different tool to approach grouping our users to make sure we were designing for everyone. And mindsets kind of naturally [laughs] for researchers are a way to do it. So specifically, we developed our mindsets during Alpha whilst we're doing initial prototype testing. We kept hitting this, the same problem in our journey, that at the point in our journey where we needed users to either create an account or sign in, we were seeing a lot of people choosing to sign in, which was just a bit odd because this was before we'd gone live. So obviously GOV.UK Account was a new account. In theory everyone should be choosing to create an account at that point. And when we spoke to people in the sessions to understand what was happening, what we realised was they were getting confused. They had existing government accounts like a Gateway account or a Verify account, and they were trying to use the credentials from those accounts to, to sign in at that point. They weren't understanding that this was a different type of account and many of the people and different teams in the project looking at different areas of single sign-on, they were seeing the same results as well. So we kind of knew it was a common issue. Naturally we tried to test lots of different variations of the journey to try and resolve that confusion. But the more we were looking at it, the more we could see, there were these, sort of, 5 common groups of participants that we could see coming out of it, and those were the groups that ended up becoming our mindsets. So these mindsets were basically focussing on how much previous experience these participants have of using government services and having government accounts - how confused would they then get at this point in our journey? And really importantly, how were they feeling about that and how were they reacting, what were they saying? So, for instance, participants with very little experience of government services, who didn't have previous accounts, they showed absolutely no confusion at this point in our journey, and their attitude was very much, "OK, fine. If this makes sense, what do I do next?" So those were our clean-slate mindsets, because effectively, that's, that's what that group of users were. But then on the other end of that spectrum, we have participants who, you know, they did have an existing account, like a Gateway account, as an example, and they used it quite frequently. And when they hit this point in our journey, they were getting really confused about what to do. They're trying to sign in, and they weren't understanding our error handling about why they didn't have an account and they were reacting really negatively to it. And there were different reasons why they were reacting negatively. But they kind of all revolve around the issue of single sign-on and the fact that we have multiple sign-ins and accounts that exist today. So for some participants it was the case of, they had a Gateway and it was the only account they'd ever needed because they'd only ever done stuff relevant for Gateway. So they thought that was a single sign-on, and they thought it was a single sign-on because they had the expectation they should only need one account when interacting with government. And for other participants, it was more the case of, they were just frustrated because they'd need to create another account. That's another set of credentials to remember. And they also need to remember where to use those credentials. So, yeah, we found these different groups coming out and ended up with five mindsets overall, which we were then using to input into our design process. Vanessa Schneider: So you mentioned the Alpha assessment. Can you share a little bit about the feedback that you received? Lauren Gorton: Yeah, so, so within our Alpha assessment. So we had another user researcher, one from Department for Education, who was our assessor for the user research aspect. So. They were very happy with the mindsets approach. They thought it was a good way to look at user needs and to try and understand our users. So we actually followed that up with a session where we kind of explained mindsets and they did another cross-session where we broke down user needs in a better way. So it was kind of turned into a cross-learning opportunity so that, that was, that was quite nice to do. Vanessa Schneider: Great, thank you for giving us this overview of mindsets. I was wondering how it might be relevant. How does it strengthen the understanding of complex user needs, maybe beyond single sign-on? Lauren Gorton: Yeah, definitely. So mindsets they're, they're not unique to single sign-on, they're a really nice tool to use if you want to group users in a different way to personas. So how mindsets were most helpful for us, is, you know, we had a problem that we were trying to understand better why this problem was happening, why people were behaving that way and the reasons driving it. So with our mindsets, they were really useful in designing error scenarios in particular. So we knew, “OK, we've got these groups of users. And at this point in our journey, this group in particular is going to struggle. And the reasons why they're struggling is this. So do we need to put content here to help? Do we need to change the design pattern? If we do that, is that going to impact a different group of mindset?” So it gave us that kind of better picture of how to design with our users in mind and also really help with our user needs as well. So we already had our list of user needs that we had insight on, so we could sort of look at those user needs and say, "OK, do any of these apply more strongly to different mindsets? Therefore, do we need to think about those needs more so when designing for this particular group" and in reverse, we could also say, "OK, now we have these mindsets and we're understanding a bit better why people are behaving the way they are. Can we now see new user needs that we missed before?" So yeah, it's a really nice tool to use that is a general tool. So it goes beyond single sign-on and is really a good way for other government teams to, to better understand the way people will behave and the reasons why. Vanessa Schneider: You've done user research with citizens now, you've done user research with other departments. How does it feed into the development of the programme? Lauren Gorton: Yes, so one of our next deliverables in the authentication team will be around account recovery journeys. To create a GOV.UK account, you need to link it to a mobile phone number so that you can authenticate with SMS codes. So when we went live with our MVP [minimum viable product] in October, we knew that account recovery was missing, as a gap for anyone who then loses access for their mobile phone. So it was kind of on our radar as being something that we, we knew we need to-- needed to address at some point after October. Since going live, we have our feedback form, which is one of the best ways for research to really feed into that sort of roadmap and what to work on next. And yeah, in our feedback form we're getting the feedback from people that they are hitting this issue. So that was something that was already planned to do because we'd identified it as a design gap. But the feedback form is helping us to say yes, no, this is definitely a right priority to pursue because people are experiencing that in live. And similarly, also on the themes of mobile codes: again, the feedback form data is also now telling us that the codes are an issue for anyone who lives in a poor signal area and people with international phone numbers, so that's helped us to identify, "OK, actually this is, this is also our next priority the team needs to pick up". So, yeah, we've done some extensive desk research on an alternative to mobile codes, including looking at the whole cyber aspect and security. And we're now doing the design work to introduce an alternative to SMS codes that we can add in as an option for anyone who's either struggling as, as they've told us in our feedback form or who just, they would prefer to use an alternate option. Charlotte Crossland: Yeah, so I guess our work feeds into both the authentication and the identity product, so our work stream is really committed to delivering and inviting service teams into that auth[entication] onboarding journey. So we're now accepting private beta partner requests for service teams and central government. We'll also be doing groundwork around how to add an account to that onboarding journey, and we'll be looking to publish the technical documentation live on the product page. We're also feeding into the identity stream of the programme as the identity onboarding journey will follow in the third quarter of 2022. So we're really doing that groundwork of developing materials to help teams make decisions around identity strengths, around levels of confidence. And this will ultimately play a central part to that identity onboarding journey. And I think it's not just a one-way approach, so we've been working with identity experts within the programme as well to create an identity tool which uses questions and answers to help teams understand what identity strength could be appropriate for their service. So that's helping us really to bridge that gap between the guidance that is already out there and helping teams make decisions and initial feedback from research has been really fascinating. So by translating some of the logic that GPG 45 sits on, we've been using that and turning it into a really more interactive and accessible format for teams. And we're seeing teams really play around with the tool, and it's really empowering them to consider what solution might be most appropriate for their service. And we're also seeing how these materials could help teams navigate conversations with security or risk teams within that department. Vanessa Schneider: Brilliant, so you had mentioned the registration for the private beta. How exactly do folks get involved? What are the steps they've got to go through? Charlotte Crossland: So the easiest way to get involved is to go to sign-in.service.gov.uk. You'll see the GOV.UK Sign-in product page and there'll be a section there saying "Register your interest". So whether you're interested in log-in and authentication or identity, you go to that form and fill it out and then we'll be in touch. And then from there, we'll do a half-hour chat to understand your service at a high level and you'll be then in our pipeline, where you'll be triaged to the relevant next steps. Vanessa Schneider: So if you're part of a service team in government and if all of this has piqued your interest, get in touch. And if you want to go back to the previous episodes on digital identity and other topics, you can listen to all episodes of the Government Digital Service podcast on Spotify, Apple Podcasts and all other major podcast platforms and the transcripts are available on Podbean. Goodbye. Lauren Gorton: Bye. Charlotte Crossland: Bye.

The Government Digital Service (GDS) talks how to start a career in tech. According to a Tech Nation Talent report, young people could be wrongly counting themselves out of a fulfilling career because they’re worried about things like their skills background, where they came from or their lack of “network”. We asked 3 of our developers to respond to the report’s findings, and hopefully put some of those myths and misconceptions to bed.   --------- The transcript of the episode follows: Louise Harris: Hello and welcome to the Government Digital Service podcast, and our last episode of 2021. Today, we’re going to be talking about careers in tech. Now chances are, if you’re a regular listener, you’re probably already working in a digital, data or technology role. Maybe in government. Maybe in the public sector. Maybe somewhere else entirely.    But hopefully you’re aware of, and are sort of bought into, the long-term career opportunities, flexibility, creativity and satisfaction that a job in tech can bring. But unfortunately, according to a Tech Nation Talent report - that’s not the case for everyone. They surveyed a thousand 15 to 21-year-olds and tuned into almost 80,000 Reddit conversations to understand what young people in the UK thought about a career in tech.   In that research, 32% of men and 45% of women worried they didn’t have the right skills to pursue a tech career. And 24% of women and 21% of men said that tech careers weren’t for - and I quote - “people like them”. People in the UK feel that there are barriers standing in the way of them getting into tech. And they’re potentially counting themselves out of a great career as a result. Which is bad news for them, and bad news for all of us too.   Because diverse teams are better. Teams that reflect the society they serve are more effective. And teams where you can bring your whole self to work are - frankly - happier teams to be a part of. And that’s what we’re trying to build here at the Government Digital Service.   So we decided to dedicate this episode to anyone who is thinking about starting a career in tech - whether they’re 22 or 62 - but who’s maybe been put off by a little voice (or a loud one) telling them they shouldn’t or can’t.    Joining us now are senior developers Rosa Fox, Iqbal Ahmed and Kelvin Gan. They’re going to reflect on what the research found and hopefully, put some of those fears to bed. So Kelvin, Iqbal, Rosa - over to you.   Iqbal Ahmed:  Hi to everyone I'm Iqbal and I'm a senior frontend developer at GDS, which is at the Government Digital Service and joining me today, we have Kelvin and Rosa, who are both senior developers as well. We're here today to chat about some common misconceptions about pursuing a career in tech. I've just been handed a list of things that people, particularly younger people, seem to think about tech careers, and I'm excited to find out what the three of us think about these sort of myths or preconceptions that people have.    So the first one we have is “I don't have the skills to work in technology”. So Rosa, what do you think about this common preconception?   Rosa Fox:  Well, firstly, I think that there are many different jobs underneath the umbrella of technology. So it's not just coding skills. So at GDS, we have jobs such as being a developer, where you do do coding. But we also have designers, project managers, delivery managers, performance analysts, content designers. So, those jobs all require lots of different skills, and you probably already have a lot of those skills. So it could be things like breaking down problems, communicating, being creative, helping other people. And so I'd say you probably already have a lot of the skills. And if you feel like there are some skills that you don't have yet - yet being the keyword - then there's always options to learn.    What do you think Kelvin?    Kelvin Gan:  Totally 100%, I agree with that. I think as well the main thing with a lot of people is that learning on the job as well is a big thing for us, like we have apprenticeship schemes, so you can join us as an apprentice. We put you through a bootcamp as well. So Makers Academy is a London-based bootcamp. And you spend, I can't remember how many weeks, 12 weeks or something like that with them and you get taught on the job and you’re mentored by us as well. We've got a mentorship scheme within.    You’re not expected to know everything on day one. I mean, even I as a senior developer, like I've ok doing this for over a decade and every day I'm learning something new, like it's totally OK to turn up and go like, I need help. I need to learn this. And I also know people who switch careers later on in life, so they want to learn coding. They just do it, you know, you can teach yourself as well. A lot of people we've been working with have taught themselves. Yeah, I don't think you need to worry too much about it.   Iqbal Ahmed:  Yeah, yeah, I totally agree. I'd say probably one of the big things I would say is like, just try different things out and just see what you enjoy. And I think like, you know, if you do enjoy it, then just get stuck in and just try and learn what you can then. Definitely, as Kelvin was saying, yeah, once that you get into the job and you get stuck in and you kind of get a real feel for it and just the learning, you’ll just learn really quickly, just pick things up really quickly. So, yeah, thank you for that.    So onto the next one. A common myth is “I don't know anything about tech. I’ll never be able to get a job”. So Kelvin, what do you think about that?   Kelvin Gan:  I-I don't think people nowadays really know nothing about tech because we're using tech every day quite honestly, like you've got a phone; you’re using tech you're on, I don't know, whatever social media of the day is, whether it's TikTok or something else. You know you are interfacing. Sorry, interfacing is such an icky word [laughs]. But anyway. [laughs]. You are using tech every day. You just don't really know it. And if you are in- if you enjoy using tech, that actually is the spark. That's the beginnings of it, you know. And more than anything, it's really about curiosity, like you’re using tech and you kind of thinking: ‘how does this work?’ But the other side of it is: ‘how do people use tech?’ ‘How do people benefit from using tech?. And actually that’s like product thinking, for example, like, how can we–or design thinking you know; how can we deliver services to people that are useful? Will make things better for their lives? That kind of stuff, it’s not just about learning the ins and outs of the technical aspects of how things work.    What do you think Rosa?   Rosa Fox: Yeah, I completely agree with that. I think yeah, you mentioned like phones and social media and technology. And technology just powers so many things; like the way that we consume music and videos, banking, gaming medicine, the energy industry. I read the other day that apparently there's a 100 million lines of code in a new car. So there's probably so many ways that you're using tech without even realising it. So I think whatever your interest is, there's probably a way that it intersects with technology somehow. So that could be quite a fun way to get started.   Iqbal Ahmed:  Yeah, yeah, definitely. And I think I've worked with colleagues that have done, had a degree in fine art. Someone else had a degree in history. You just get like so many people just coming into so many ways to get in. And the team was saying earlier, like apprenticeships and we’ve got these Fast Stream sort of opportunities as well. There is loads and lots of ways to get in there. So yeah, yeah, yeah, tech is everywhere.    So, yeah, so next one we have is that we have to do lots of unpaid internships or work experience in order to get tech jobs. So what do you think about that, Rosa?    Rosa Fox: Well firstly I think you should never have to do unpaid work, and I think it's, you know, it doesn't create a very good balance in society for people to have to do unpaid jobs because obviously you need a certain safety net to be able to do that in the first place. So if that's not an option for you, then I'd say, don't let that stop you and don't give up. You know, you might be able to find apprenticeships or junior positions or ways that you can learn on the job. I'd also say there's a lot of things that you can do to kind of teach yourself - you could go to maybe technology events. There are lots of free meet-ups that you could go to. There's loads of resources online that you can learn from.    And also kind of maybe looking for someone that can give you a bit more advice about tech careers, even like messaging people on LinkedIn or social media and asking them some questions because often people are quite you know, flattered to answer questions about themselves, and about working in tech. So you know, they might know of some openings for you know, for ways that you can learn skills, hopefully whilst you're still getting paid as well.    Iqbal Ahmed:  Kelvin, what do you think?   Kelvin Gan:  Yeah, I totally agree about not doing, not even having, hosting unpaid internships because that's just exclusionary, and it's not really what we're about here at GDS. But again, you know, hammering home the thing about apprenticeships, they’re a perfect way of getting started, and we're really behind it at the moment. We've got new apprentices starting just early next week, in fact. And I know a bunch of them from years gone past have gone on to graduate into junior roles and have also been promoted into mid-level roles. And they're just great and they really enjoy it as well. And then others have gone on to work somewhere else you know. We put that investment in because we want to put back into society as well as, you know, getting good people through the door to come and work with us.    And again yeah, like Rosa was saying, there’s loads of meet-ups. A load of people will turn up and also coach you, Rosa and I have done that in the past as well. I think Rosa you're still doing that right? I haven't been doing it as much during the pandemic, but yeah, go along to, like loads of free resources, online meet-ups. Great thing about the meet-ups is that you get to meet people who are in the profession and so you can ask them questions straight off, like face to face or online. They also host like, I was going to say Slack channels for people to ask questions. And I also saw a meme today, a tweet today where someone’s son asked them when they saw them using Slack: “oh what’s that? Is that Discord for boomers?”. And that really hurt [laughs]. So in case you don’t know what Slack is. It's kind of like Discord.   Rosa Fox:  I will add as well as going to community things, a thing that can maybe help you with finding work is to build a portfolio up. So, you know, a portfolio sounds quite a fancy word, but it could be like, you know, a short blog post or building small projects. They don't have to be anything complicated, just any small thing that you can learn, even doing a tutorial. If you put that up online and show people that you're actively interested in learning then people will probably be interested in giving you feedback and maybe even a job.   Iqbal Ahmed: Yeah, yeah, I totally agree with that. Like, GitHub is really good; a good place to post code and things like that. And if you show like an active GitHub profile; so you know, even just any tutorials or things like that, it’s a really good place to kind of put those up there and just show your kind of keenness and passion for coding and learning and things like that. So. Cool. Yeah, thanks for that.    And the next one we have is that: “it's not for people like me”. So like the tech career or something, might not be for you know, certain people. So Kelvin, what do you think about that?   Kelvin Gan:  I would 100% disagree with that. I think the, for us, the key thing for me, anyway, when I'm working with someone is whether they think about who they're working for. Not the sense of not who your employer is, but who your end user is. Like, that's the way, that's the kind of person I like working with. And that's the kind of people we get in. We come here to do the work for, to help people really at the end of the day. And if you've got that kind of philosophy and attitude, then I don't really care what your background is, where you live, where you come from, whether or, what your first language is, what your favourite food is, all that kind of stuff. Like whether you went and got a university degree. Nah you know, if you come in and work with me and what you care about is what we're delivering for the user, then that's it. And that, you know, you like tech. Enough.   Rosa Fox: Yeah, agree as well. I think kind of like we mentioned earlier, technology is absolutely everywhere now, and it has so much impact and influence on society. And you know, if you use technology, then you should be able to influence how it's built. And we want a diverse range of voices and people working on the products because, as Kelvin mentioned, the products are used by a diverse range of users. So, you know, more perspectives, more different types of skills and more different types of talents, that's going to create a more diverse team and that's going to make much better products. So, yeah. No, you've always, you're always going to have things to bring to the table and things that might be different about you are probably things that could be really, really useful for the team and you should always you know, be proud of your differences because they make you who you are.    Iqbal Ahmed:  Yeah. Go for it Kelvin.   Kelvin Gan:   Sorry. And one thing I was going to add to that is like, we, you know, I personally like to advocate for people to bring their whole selves, bringing in that difference, it’s exactly as you were saying there as well, Rosa. Sorry, Iqbal go on.   Iqbal Ahmed:  Yeah. Yeah. No. And I was gonna say that at GDS you can see people are keen to kind of spread opportunities to, you know, just try and go out there and try and interact with other of communities and people from different, diverse or backgrounds. And I think GDS is quite keen to get people from different viewpoints and things like that. And that's something, yeah, I think we're very keen to get people in. And yeah, and I'm very proud to sort of work at GDS, because the services we provide, there's no alternative. So you're applying for your driving licence or something like that or paying for some sort of government service, you can't just go to a different website and you know, buy that thing. It has to–we need to make sure what we have is available to everyone. So, yeah,yeah, so that's something that's really great about working at GDS. But yeah, cool cool. Thanks for that everyone.    And the next one we have is: “there aren't many tech jobs around or near me. So that could be a myth some people are using to potentially hold them back.   Iqbal Ahmed:  Cool, Kelvin, any thoughts on this?   Kelvin Gan:  I think for us in particular, at GDS, we support remote working and we're very flexible as well. And like in terms of having to go to an office like we have our three main hubs at different corners of the country. So we've got London as our base. We've also got Manchester and Bristol and so those other parts of the country, you know, we've got these hubs for people to get together and meet and work together anyway. So hopefully it'll be a bit closer to you. Yeah, you know.    It also gives you an opportunity sometimes if you want to go and move somewhere else in the country and work somewhere for a bit, and then you can jump any, like tech jobs are everywhere in the world. So I think that's pretty cool as well about the industry.   Iqbal Ahmed:  Yeah, and also another thing is I think, like Rosa was saying earlier, tech isn’t just Developers and people like that. I mean, there's loads of other opportunities like Product Managers, User Researchers, Content Writers, Delivery Managers. There's so many things. It’s always changing and evolving all the time as well so. Yeah, there could be more jobs out there, it’s just maybe widening the fields and thinking about other things that you might be interested in.    Cool. So the next one we have is: “I don't know anyone who works in tech and don't know where to start”. So, Kelvin, any ideas about this?    Kelvin Gan:  Yeah. So it goes back to finding the meet-ups and networks; you know, like they can be quite varied and niche in themselves as well. So say, for example, you might be someone who has a Raspberry Pi through school or you got given one or whatever. And a lot of meet-ups around the country are centred around that. People who have those want to get together and talk about how they play with theirs or do stuff with theirs, you know. And that's a good in. That's how you can get to know people.    The other thing as well, is the kind of code clubs in the area and just go along, meet them as well, like just introduce yourselves to people or start one, like Rosa did! And it's all online as well. Like, you can join a chat somewhere and say: ‘Hey, I'm really keen to learn JavaScript, I’m totally new to this thing’ and people are going to be like: ‘Oh, great. Welcome to the family, here’s some stuff with, you know, we think you can get going with. Oh if you're stuck with this, this is the way we fixed it’ - that kind of stuff. You know, it's nothing to be frightened of. We're a pretty welcoming bunch. You know, we as a culture, we will–like to kind of help each other out a lot as well.    Iqbal Ahmed:  Cool. Nice. Rosa, any thoughts on this?   Rosa Fox:  I guess I'd add to that to say using social networks can be quite good as well. I know that social media isn't for everyone, but for example, on Twitter, when I first started working in tech because, like I said, I didn't know anyone that really worked in tech, I just followed lots, lots of people, and I barely really post on there. But I do still go on there and read sometimes. So that’s quite a good way to learn about things, learn about conferences or events that were happening, watching, reading their blogs, reading reports that they posted. I know that there are a lot more kind of Instagram tech bloggers now that are really interesting and also people on YouTube. So there's a lot of, you know, there's a lot of people that are posting about tech online and lots of great people to learn from. So, yeah, that would be my advice.   Iqbal Ahmed:  Cool, yeah, I was actually helping out some network and some group of coders, and they asked if I would mind just providing some mentoring and I really enjoyed it- it was really nice, just like people would just book a calendar invite with me and we just did it online. And it was just 1 on 1, some people were brand new and didn't know much and asked me some questions. And yeah, I really enjoyed it. Really liked sort of chatting to the people. So what you'd be surprised that there would be people out there if you did reach out to them that they’d be more than happy to spend some time with you and help things out. And I do actually know a few graduates actually that reached out to people on LinkedIn. And surprisingly, they got quite a few responses back and a lot of help. So I'd say LinkedIn is really good as well so if you do see anyone, just try and sort of send out a few messages - you just never know.    Cool and now we are onto the final one, which is: “it's no fun to work in tech”. So Rosa, what do you think about that?    Rosa Fox:  I think working in tech is really good. I mean, it's a job where, you know, you get to build things that potentially I mean, on GOV.UK, millions of people use our products every week. So it's amazing to go from having like a plain text file on your computer, writing some code. And then as a result of that, you've got something that people can actually use and interact with. And I think that's like really amazing. It's nice to be able to you know build things that help people and again, that people can use.    It's also a really creative job. So I think people assume that working in tech is quite like nerdy, and it's just the people that don't see the sunlight  you know sitting in the basement coding all day [laughs]. But actually, it's not like that. There's a lot of collaboration. It's very creative. You know, you have to kind of think of an idea and make it happen.    And also, the tech industry is generally like, it's quite fun. You know, the tech offices are generally quite cool. They’re usually made in a way that there's space for a lot of collaboration and communication. And I think my favourite thing about working in tech is that you're always learning, things are always changing, it's always evolving. So you never get bored. Sometimes it can be a blessing and a curse because there’s so many things to learn. But as long as you’re kind of like, try not to get too overwhelmed by the enormity of it and just, you know, start small. It's amazing what you can even learn in like one hour. Have a break, do something else and then come back again. So, yeah, I think that's definitely my favourite thing about working in tech.   Kelvin Gan:  Yeah, definitely. Like it is a deeply rewarding role as well. Like Rosa, you're talking about like building something useful you were on the Critically [sic: Clinically] Vulnerable People Service at the start of the pandemic, and that is like mind-blowingly useful, actually like life-saving, you know, sending food to people who are isolating and can't get out at the beginning of the pandemic. And that had so many people involved in it as well, didn't it? And like again, for me as well, working on GOV.UK, the impact that we have on people's lives is so like, it’s a huge responsibility, but it's super rewarding. And then there is the fun aspect to it as well, like you are working with like a huge discipline, sorry a huge variety of disciplines and the types of people who are just really, really great people and really fun to work with.   Iqbal Ahmed:  Yeah, one of the other big things I've noticed as a sort of Frontend Developer is the focus we have on accessibility. So as I was saying earlier in terms of making sure our apps work with uh screen readers and other sort of accessibility tools, like we spend quite a bit of time on that. And yeah, I've just never had that anywhere I've worked on so, and I've worked quite a few years in the private sector. And so, yeah, I really kind of enjoy that at GDS. And also as Kelvin and Rosa are saying, you get to work with Service Designers, Content Designers, Delivery Managers, there's all these different kind of disciplines that you kind of all work together when you produce something and you get like really good feedback from it as well. It's like a really good sort of rewarding sort of feeling. So, yeah. No, amazing, good stuff.    So I think that's brought us to the end of our conversation. So yeah, just like to say thanks to Kelvin and Rosa for chatting to me today and sharing what they know about a career in tech. Hopefully, we've convinced you to think again about whether a career in tech is right for you and - hint hint - to keep an eye out for opportunities to come and work with us at GDS. So you get to work with great people like ourselves [laughs]. And also you can find more about GDS and the work we do at gds.blog.gov.uk. And we also have a podcast and we're also on the socials @GDSTeam and we’re, yeah, you can find us on Twitter and Instagram. And you can find the latest job opportunities just by searching for GDS careers on Google. So thank you very much, and thanks again to Kelvin and Rosa as well. See you later, bye.   Louise Harris:  So big thank you there to Iqbal, Rosa and Kelvin for sharing the myriad ways you can find, and get into a career in tech - whatever your background or starting point.    Don’t forget, you can also find all of our other episodes on Spotify, Apple Podcasts and all major podcast platforms and our transcripts are available on PodBean.    Thank you for listening - and see you in the new year.

We take you from A to B as we find out how the GOV.UK Design System and Department for Environment, Food and Rural Affairs working to help make maps in public services better. You can help us to make our podcast even better by completing our short, anonymous survey.   The transcript of the episode follows: ---------   Louise Harris: Hello, and welcome back to the Government Digital Service podcast. My name is Louise Harris. I'm the Creative and Channels Team Leader at GDS and your host for today. Before we dive into the episode, I've got a quick favour to ask: if you are a regular listener to the GDS podcast, please take a second to fill out our quick 2 minute survey to tell us why you tune in, what you like and what you don't. You can find a link in our blog post and the show notes for this episode. Anyway, on with the show.    Today we're going to be talking about maps, more specifically maps in public services. Here at GDS, with a little help from our friends, we've started to explore how to make public sector maps more consistent, easier to use and accessible for users. Sound good? Well stay with us because there are lots of opportunities to get involved in this work. Whether you're in central or local government, wider public sector or even outside. To get us from A to B on this interesting topic, I'm pleased to welcome Imran Hussain, Community Designer for the GOV.UK Design System, and Cathy Dutton, Head of Design at Defra. Cathy, Imran, welcome to the GDS podcast.    Imran Hussain:  Hi Louise, thank you.    Cathy Dutton:  Hi Louise.    Louise Harris:  It's great to have you both. So I've introduced you to our listeners, but you don't need an introduction to one another because you go way back. Is that right?   Imran Hussain:  Yeah, we do. We used to work out Defra together, not so long ago actually. Before I came to GDS. So I was the Communities Lead at Defra and I worked with most of the communities in the user centred design space and with Cathy being the Head of Design. We got to work together quite a lot. And it was lots of fun and it's sad that we don't work together anymore. So it's absolutely brilliant to be on this podcast with her again.    Louise Harris:  Cathy, I hear on the grapevine that GDS sort of semi poached Imran over from Defra - have you forgiven us yet?    Cathy Dutton:  Yeah, almost. It helps, we-we still get to work together. So it's all good.    Louise Harris:  So you've both decided to join forces and try and unpick this kind of a sticky challenge of making maps that are used in our public services more accessible, more consistent and, well, just, better. Imran, I'll start with you because I think you and others in the GOV.UK Design System are gonna have a big part to play in coordinating these efforts. But for those listeners who maybe don't know much about the Design System or design in government in general, can you give us a quick kind of whistle stop tour into what the GOV.UK Design System is, what exists to do and what your role as a Community Designer involves?    Imran Hussain:  Yeah, of course. So the GOV.UK Design System is a suite of tools that helps teams in government quickly build usable, accessible services for GOV.UK. You can find it in more than 3,000 repositories on GitHub, and they use different elements of the Design System. On GOV.UK alone, it's used on over 7,000 individual services. But there's many more outside of it as well. So, yeah, it's vastly used and really, really popular, and we kind of need it in government. My particular role is Community Designer on the GOV.UK Design System team: I work with the community. I kind of create space for collaboration to happen, which is really important because we're a contribution based design system. So most of the ideas for components and patterns and things like that come from the community and the community actually build a significant part of those patterns and components as well. So we just kind of do the finishing touches on the team.    Louise Harris:  So that, to me, sounds like it's almost as much about the people as it is about the tech or the design stuff. Right? So it's about creating that environment where a sense of community can really take root.    Imran Hussain:  Yeah, that's that's absolutely, really important.    Louise Harris:  Thinking about this maps work, is that something that's kind of come up from the community?    Imran Hussain:  Yeah, of course. Yeah, it's completely come from the community. And it just came about because it kept coming up on Design System calls. It kept coming up in our forums, people asking about what's the best practice with how to do things maps-wise. And we keep getting help desk tickets around maps as well. We-we've got 2 levels of users on the Design System team. We've got you know, the end users, which are the general public that will use these maps, but our primary users, I guess you could say, are designers and user researchers; and yeah, whether they're interaction designers, service designers or content designers across government who use these components and patterns. So it, it clearly came up as a need and we didn't have the relevant components and patterns to be able to serve their needs at the time, so we-we started this collaboration. And it-it was Cathy that really kind of kicked it off because they, they came up with some things and just kind of said: 'hey, where do we share this?' [laughs]. So now we're creating a space where everyone can share things.    Louise Harris: Oh, that's really cool, Imran. Cathy, it sounds like maps is something that Defra's been thinking about beforehand.    Cathy Dutton:  Yes, so maps is something that comes up in discussion in Defra a lot. We have weekly drop in sessions that are often around like how we can do maps better. They've been a lot of our services, like flooding and farming, and we did our first accessibility drop-in session last week as well. And the whole top--a lot of topics were about how, how we can make maps more inclusive. So because we speak about it a lot, we try to start documenting some of the stuff we talk about so we don't just repeat the same conversations. And I think it was last summer we started to create our own version of like what mapping standards could be or the beginnings of map standards and guidance - really high level stuff, just like when to use a map, some of the findings we've got, some of the best practise bits - and we, we put them on GitHub. And then for me, that's been really useful because part of my job is speaking to all the designers. So whenever we have someone new join or whenever someone gets in touch and says like: 'we're doing a map, where do we start?', I can kind of point at the, at the standards. And that's how we got involved really. I think I came to one of Imran's calls on a Friday and was just like we have this thing, how can we share it across government because it's not a pattern or component? Or how can other people in government input and improve it for us?    Louise Harris:  And how has that been then? Being able to tap into that wider community across government and see you know, this-this baby that you've been creating in Defra, how has it been watching that grow?   Cathy Dutton:  It's been really good so far actually. The mix of people on the panels that Imran's put together has really helped because we've got, like our efforts were mostly from interaction designers, service designers and content designers. So it's been good to get people from different backgrounds, software development, data specialists and get their input and see what, where they're coming from when we talk about maps. That's been really useful. It's been really good for our designers as well. There's a few Defra people on the panel. So just getting them exposed to like different ways of thinking or different, different, what's the word I'm looking for, constraints around mapping or how we do good maps has been really helpful.    Louise Harris:  And have there been you know, themes coming through in terms of what teams are kind of struggling with when it comes to maps?    Cathy Dutton:  I think so, yeah, there's one particular one in Defra that, we, we kind of go to shape tools quite early and trying to make a shape tool on a map like draw like something out, a position on the map is really hard to make inclusive and accessible. And so that seems to come up quite a lot and could be one of the biggest challenges. We've tried to just start saying it in a different way to see if that maybe helps and just say like a lot of stuff in Defra is: 'can I do this activity in this place' and just trying to find different ways that people could do that. But if we do need a map, obviously it's useful to have standards.   Imran Hussain:  And we-we've just been talking about standards recently, and there was a few different areas that came up like Cathy said, because we've got that really multidisciplinary steering group. We talked about: we wanna include features on architecture, what technology, user interface, data visualisation and accessibility. So those are the different areas that have come up already in terms of any sort of standards or principles that we will design.    Louise Harris:  There’s already quite a lot of energy and interest in exploring this issue. Do you have sight of your end, end goal at this point?   Imran Hussain:  For, for me, it's always based on what the community want to do. So we asked the community and we've put the steering group together, and what people want is really practical things that they'll be able to use in their work. So it's nice to have, you know, the things that Cathy mentioned about getting people together, getting them to learn from each other, we do absolutely want that to happen. I think people want to have real, tangible products or things that they can kind of use. So in a, in a, we've got like a short term and long term aim that we've been talking about amongst the steering group. And the long term aim is to kind of set best practice and develop specific things that people can use.    In the short term, what we're going to do next is probably get together and set some best practice and create some principles, some design principles for maps across the public sector. And we see that as the first step where we get everyone pulling in the same direction. People understand what good looks like and hopefully start changing their practise to try and work in with those kind of principles. Once we have those and we kind of help proliferate those around in the public sector, then I think what we will try and do after that is start to create those specific patterns and components that people can then utilise in their services. So you know, we've shown people what good looks like, what the principles are, then we start getting more specific with: let's design this element of mapping and get that same community in to give us their best practise and we'll create a component that everyone can use.    Louise Harris: You talked a little bit, Imran, about us having 2 users of the Design System; we've got our ultimate end users: so the people that live in our communities, my friends, your friends, our parents, our colleagues who are gonna be needing to use government and public services; and also our kind of primary users in this context: the service owners and designers and content designers that are going to be building these services and maybe using maps. What's the impact for them if we don’t fix this work?   Cathy Dutton:  Yeah, the biggest, the biggest problem is probably making maps that are accessible and inclusive because it is, they can be quite complex. As soon as you have a map, suddenly you've got layers, you've got keys, you've got things that fly in and out. So it's been, it's been about making them accessible and making them work on mobile devices as well, where some information is hidden. We always have, like one of our standards, one of the first 3 parts of our standards I think, is that if we use a map, you have to make the information available outside the map as well. But that is also quite tricky depending on what the information is. So that's something that we always come back to is like, how can we make maps inclusive?    And then I think as well, we've started talking a lot about sustainability in, in, in Defra, in design in general. And so like maps are quite data heavy. So they're probably not the most efficient way we can use data either so that's something we're starting to talk about more and more as well. And then even just like as you're prototyping ideas, you really want to prototype stuff like quick and use throw away code and testing and try again. We haven't found yet a really quick way to test maps because i-it's quite an effort to do a map in a prototype. And so even just that kind of stuff is a problem. Like if you want to quickly test something, how do you quickly test a map? And we always start without a map, is our default anyway. Start with the, the very bare minimum and see if there's actual need for a map.    Louise Harris:  Yeah, it's really interesting, and I think there's, there's maps and there's maps, right? I think some people might immediately jump to maps as navigational tools, getting us from A to B. But actually, as you've talked there, sometimes they're conveying data about a particular area.   Cathy Dutton:  Yeah, I guess flood, flood is a good example. So the flood maps: you can find out your risk of flooding on a map. I think it was traditionally with icons on maps, which is another, another problem for, for inclusivity. So in that service now, they've done a really good job of using the map as like a secondary tool. So you can find out everything you need to find out about your flood risk. And then if you want to do it on a map, you can. And so that's like working well in that area. Yes, some maps are interactive maps and some aren't, some are just information. The interactive ones are harder, like if we're talking about the shape tool again. We're still trying to work out how you would make a map where you've got to draw shape on it. How can you do that outside of the map? And if you have 2 ways to do it, is that more efficient or is there 1 way? I'm always wary of like 1 ways, 1 way, like there's never one solution for everything.    Louise Harris:  Well it sounds like that's why you know, working towards these standards is such a good first step because it’s, it’s a pretty big problem, pretty broad area that maybe no one’s got quite right yet.   Imran Hussain:  I think it's important to recognise there's a lot of good work out there currently. So there's lots of departments doing really exciting stuff. And i-it was just by chance that I knew Cathy and she's happy to discuss these kind of things with me, that she came and she shared her work; and they told us about, they-they did some great work with accessibility and tried to apply some principles that usually wouldn't apply to maps - like hover over text and highlighting text and things like that. They tried to apply that to maps, and a lot of people don't. But it-it's just by chance that I found out about the work she's doing and we were able to share it. So a-and part of the problem is that if we don't create that space where people can share and feel comfortable sharing and they think that it's going to actually go somewhere, then it'll just stay in silos in different organisations across the public sector and we'll have pockets of best practice. There'll be no consistency and it'll only be people in the know that find out about it and try to implement those kind of fixes. So it's a real great opportunity.    I mean, it's really intimidating to try and fix maps, which I keep joking about: 'oh, Imran, what are you doing on maps?'. We're trying to fix maps in the public sector, but it literally is as wide as that, it's an open goal, you know? There's...no one's got together so far and put the effort into building a set of standards or deciding what good kind of looks like. So as far as I'm concerned, anything that we sort of achieve will be a step forward from where we were before. There's lots of great stuff out there, we're just, you know, I'm, I'm really just kind of collecting it together. I've, I'm, I've got no expert in [laughs] maps, no expertise whatsoever in maps. I'm not a designer, but I'm, I'm good at collaboration. So like, I'm just gonna get all these brilliant minds, put them in one place, get all the goodness from them and will try and put it into a nice, accessible, quite easy to understand format that everyone can kind of share.    Louise Harris:  And what do you think Cathy? It sounds like it is an intimidating area for designers to be looking at and thinking about. But it’s obviously something that you at Defra have been doing.   Cathy Dutton:  I think 'cause, just from being in Defra for like the last 5 years, I've seen how much like because I'm not a map expert either, but there's people in my team that really are. And it's taken them years of working on like flood services and working on maps and spatial information. The knowledge they've built up and the research they've collected and stuff, it just, it's, it's taken them so long and I kind of feel like now they are really, real experts in mapping and that helped us do our standards. But then I think it was just like if every other--I thought that if every other department was doing the same thing, like it just makes sense that that's something we should just do collectively. 'Cause I know that we were lucky enough to have funding to spend a lot of time looking at inclusive maps. But if that can help people who haven't got as much funding or time to sort of start from a slightly higher position by using our-our standards or even them helping us with our standards, then that just seemed like a thing we should be doing. So I'm just, I'm just basically trying to share the great work that the people in my team have done that I didn't do anything of. They all did it and just, it just felt like it was good enough to share.    Imran Hussain:  Yeah, we're, we're, we're both just here to take credit for other people's work [laugh from Cathy], really. [laughs]    Louise Harris:  Aw, I, I think you’re both far too nice to take credit for anybody's work. It feels to me like you’re championing this work.    So we’ve got GDS involved, we have got the lovely folks at Defra involved. Imran, are there any other organisations that are kind of throwing their weight in at this stage?   Imran Hussain:  What I can tell you is we, we originally planned for 60 people at the first workshop and it sold out within 2 days. So we-we had to invite 100 people to the first workshop and it sold out, the next batch of tickets sold out within like another day. So there's a lot of demand and a lot of people are willing to take time aside from their job to kind of participate in this and really make this a thing. So we're really, really grateful for that. I think there's more people, like I said, hearing about it all the time. And the people who work in this area are very, very passionate, and I'm really lucky that we found something that resonates with people.    We're central government so there's a lot of departments from central government that get involved, especially the map heavy departments. There's quite a few people from HM Land Registry, for example. But there's also people from wider public sector. So there's really good representation from local gov, who use maps in their services quite a lot. You know people finding schools, or trying to find their way around. There's a lot of map usage over there. But even just recently, someone from the police GIS service reached out to us on Twitter and see if they could kind of get involved, and someone from Ordnance Survey did as well. So it's, it's growing all the time and as far as we're concerned, the more people we can get involved, the better. Whatever principles we create, the more voices we have, the more robust they will be and the more applicable they will be to different sectors. So that's, that's really, we want to cast a wide net, get as many people involved as possible, really collaborate and come up with products that everyone can use.   Louise Harris:  So it sounds like we're in good company already, but for our listeners who might be interested in this, is it just designers that you think can contribute to this body of work or are you looking for expertise from other disciplines as well?    Imran Hussain:  No, absolutely. It's, we need people from every single kind of discipline to really help this kind of work. Obviously it's really helpful having different types of designers: service designers to understand user needs; interaction designers to really help with implementing fixes for those user needs; we need developers to help design components and patterns. But I think, like user research, for example, is a really key part of this making sure we're meeting people's needs and we understand those needs. So you know, having user researchers as part of it; content designers to help us write guidance; like--and as we said, we're dealing with architecture, technology, data visualisation, so professionals in technical architecture and people who are experts in data and mapping - it's all really, really useful and everything will enrich the work that we're kind of doing. And I mean the--right now is an absolutely brilliant time to get involved because we're still scoping all the problems. So we've, we've set design principles as our first kind of goal. But longer term, we're still kind of scoping exactly what direction we're going to take. So anyone who gets involved can really help shape this collaboration and really input their viewpoint and perspective and that will enrich the overall project. So, yeah, we're very excited if anyone wants to get involved and we'd love to have more voices, as I said before.    Louise Harris:  And Cathy, I want to come to you now because while you're involved in this work, you've also been a partner to the GOV.UK Design System in the past as well. So maybe you could share a little bit about what that was like, what it involved for you so that people who are maybe thinking about getting involved or want to know a little bit more, can understand what it's like and why it's great.    Cathy Dutton:  Yeah, the Design System working group - I think it's still called that - I was on for a couple of years. It's a quite a small panel of people, I think, from all different departments in government. And they basically just review submissions to the Design System to make sure that, I think it's around like checking quality and making sure that we're consistent, but also like making sure that everyone kind of--well I thought it was like making sure everyone felt like a part of the Design System as well, because it's like, it's a central tool but it's for everyone. So that's kind of the reason I love being on that panel, was that like you felt like you owned a little piece of it and you could contribute and have a little voice, so that was really nice.    Imran Hussain:  I'm sorry, Cathy.   Cathy Dutton:  [laughs] Yeah.    Imran Hussain:  I'm sorry, I'm apologising because Cathy had been on the working group since the start and I was the one that asked her to leave even though we're friends. [laughs]    Louise Harris:  Absolutely savage folks. Savage.    Cathy Dutton:  Wasn't that the first thing you did?    Imran Hussain:  It was. It was though. Sorting out the working group. [laughs] No. But yeah, it's, it's really nice to have this relationship with people across kind of government and like knowing Cathy, I knew she'd take it in the right way. She, she did always say: 'hey, if, if you want fresh blood to come in, please let me know'. And it, and it just gave us an opportunity at the time to really rebalance the working group to be more representative of the wider population. So we brought in lots of different roles. We brought in a more equal gender balance. We thought about neurodiversity and made sure there were people with different ways of thinking on the, on the Design System working group so we could represent their needs. We also thought about race, ethnicity, background, all sorts of things. And we're getting better. It's still not perfect, but it's much, much more representative of the wider population. And what we are starting to do, what, what we've said is people who leave the working group, it doesn't mean they're gone. I-it just means we're giving other people an opportunity to come in. So we're starting to kind of rotate our members a lot more. So people will come in, they'll stay on it for like a year, a year and a half, and then they'll pop back out and they might pop back in.   Louise Harris:  And Cathy is the proof of the pudding of that, 'cause she may not be a part of the working group anymore, but she's a big part of what you're trying to do to fix, fix maps in services. So thanks for letting us drag you back Cathy [laugh from Cathy].    Louise Harris:  And if people are interested in, in getting involved or about find--in finding out more, what should they do?    Imran Hussain:  I think the main things are: I-I'm quite available, so feel free to kind of like, get in touch with me, I'm on all the Slack spaces that I can get onto [laughs]: local-gov Slack, like cross-gov Slack. On Twitter as well, my usernames: @ImHuYorks - I-M-H-U-Y-O-R-K-S. But just get in touch and I can like add you to any of the platforms that you will have access to. The main chatter is going on, on cross-gov Slacks. There's a map in services channel.   The other really easy way that anyone can sign up though, is to join the Design System mailing list. So if you Google GOV.UK Design System, pretty much on the homepage near the top, it'll say: 'do you want to get updates?'. And you can join our mailing list. And that's the way that any information about collaboration, workshops will come straight into your inbox and you'll get pinged about it before it happens. So that's probably the easiest method for most people to get involved.    Louise Harris:  Sounds good. We'll make sure we include links to all of those pages and sign ups in the blog post that goes alongside this podcast, too.    So there you have it. We really want you to get in touch and help us on our journey towards improving the usability, accessibility and consistency of maps in public services. Thank you to my 2 guests, Imran and Cathy, for expertly guiding us through this really important topic, championing this work and, please forgive me folks, getting this important user need on the map. If you've enjoyed today's episode, and want to learn even more about the GOV.UK Design System - and let's face it, why wouldn't you? - you can tune in to our February 2020 episode of the GDS podcast where you can hear GDS's Tim Paul talk more about the roots of the Design System and its impact.   And you can find all of our other episodes on Spotify, Apple Podcasts and all major podcast platforms and transcripts are available on Podbean. So thanks for listening and thank you both again. Goodbye.    Imran Hussain:  Thanks, Louise. Bye.    Cathy Dutton:  Thanks, bye.

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!