LUCY WAKEFORD: Good morning, everyone, and welcome to the webinar: From Zero to Code – Minimising friction in local government and digital delivery.
My name is Lucy Wakeford and I’m Director of Programmes and Digital Leaders. It’s my pleasure to be chairing this session. Before I introduce our presenter, I’d firstly like to recap the topic to give anyone who might be running late the chance to join.
Budgets, time, people. These are three things in short supply on digital deliveries in local government. We know we need to be as efficient and lean as possible to deliver products and services with any measure of success, so how?
The second thing I would like to do is to let you know how to ask a question, which we encourage. Please enter a question in the Q & A window and I will collect the questions during the presentation, to ask in the Q & A in the last 15 minutes. The session will be fully recorded for you to watch back at a later time and share.
I would now like to introduce Anikh Subhan, who will be taking us through today’s webinar. Anikh is the delivery principal for Made Tech, and an agile software delivery expert with over ten years of software delivery experience. He has coached, trained, and mentored teams across multiple organisations, including public sector, start-ups, and multinationals. Through coaching and leadership, Anikh has helped teams and individuals deliver value in exceptionally effective ways, whilst continuously improving their use of agile techniques.
Prior to Made Tech, Anikh has held multiple agile coach, scrum master, agile analyst roles and has successfully managed a number of delivery teams. Anikh, over to you.
ANIKH SUBHAN: Thanks Lucy, what an introduction, thank you very much for setting that up. Hello to everyone, thank you so much for joining my talk. Welcome to my talk today, From Zero to Code: Minimising friction in local government digital delivery. It’s my pleasure to be talking at Digital Leader’s week again. It’s always a really good event, with lots of interesting and engaging talks every day, so I’m really looking forward to joining some of those other ones, as well.
Just to follow on from that introduction, to give you a little bit of flavour from my background, as Lucy mentioned, my name is Anikh, Delivery Principal at Made Tech where we build and deliver digital services across the public sector.
My role at Made Tech consists of supporting and overseeing a few of our key workstreams and a few key accounts within the local government sector. Primarily providing delivery assurance and coaching to our teams. Prior to Made Tech I’ve been in a few different agile delivery leadership and coaching roles, both consultancy side and industry side. Most of my work has been involved with coaching, training and mentoring companies in agile ways of working in organisations across the private and public sector.
You will have an opportunity to ask questions at the end of this talk, but you an also find me on Twitter and LinkedIn to get in touch with any questions or discussion points after today’s talk.
A quick bit about Made Tech and who we are. We are over 450 people now, growing really fast, specialising in digital data and tech expertise within the public sector and aligned to GDS standards. Partnering with and delivering outcomes with a few key clients in GDS, MOJ, NHS to name a few, plus a few of the local government organisations and authorities as well; Hackney, Camberwell, Westminster, to name a few of those.
Rapidly speeding up delivery and services as well as some of the wider agile tech transformation pieces across these clients. We’ve got offices across the UK with more expansion and growth to come.
What we are going to be talking through today then, we are going to cover a few key areas. We are going to cover the key challenges first that are faced when delivering digital products and services in the local government space. Lots of these we have faced in the past across our deliveries and projects in different flavours. We will then cover what we’ve learned from facing and resolving some of these challenges, and how we overcame them to ensure that the delivery was frictionless and that success was possible.
Towards the end I will summarise the key principles that I feel are the key things to take away from today’s talk to apply to your own deliveries or projects.
If we just step through to the challenge space first. In our time at Made Tech working in the public sector we have obviously worked with a multitude of organisations across central and local government. When working within local government we have experienced and seen slightly different challenges to those in central government.
Some of these challenges could be due to the sizes of these councils, some of them could be down to the amount of budget available, or even the capabilities and skillsets that they have access to. What we will do is just break that down and run through some of the main challenges that we have seen and experienced when working on building those digital products or services.
The first three that I’ve got here – I appreciate that I am painting a slightly bleaker picture here with this image in the background, just bear with me on this one. Number one let’s start with not enough budget, with budget constraints.
Working with a few of the slightly smaller councils, we have seen budget constraints, smaller budgets, and less spending power that they have. Working with one particular council we had a set budget for the build and deployment for a housing repair service. We had to make sure that the work for the build and deployment of that project came under this figure.
As we all know, when you’ve got a fixed budget and a fixed amount of money that you can spend, that’s going to have an impact on how extensive a project can be. It’s going to influence that. For example, if you are doing discovery on alpha, it might impact how far you can take that discovery in alpha, how much you can delve into or assess.
It does limit what can be done and it can limit the scope that might be included in a piece of work, as well.
The focus needs to be narrowed and stuck to as an overarching goal to ensure that the key outcomes are met within that budget. Not only that, but the limiting of the budget also limits the future scalability, reusability and compatibility of systems for the future. So, investing earlier in the process helps to build the right thing for now, but also potentially, the right thing for further down the line, too.
Number two on this list is the lack of user-centred design, not being user-focused enough. I should say there is a lack of understanding of the importance of discoveries and the need to be user centric. There have been occasions with some councils and other organisations wanting to fast-forward into build and delivery. Naturally, they will assume that they need to get something built and out of the door quickly to deliver value. That’s the key message. Some of them will have service areas where there are service improvement officers, for example, who are fantastic subject matter, experts. They have a lot of domain knowledge and are tasked with improving an area but sometimes without the user-centred design, understanding the user experience and the access to that.
Service areas can feel that they might understand their users, they maybe don’t need to do further user research. Maybe there is no mechanism for recruiting participants or money or budget to pay people for their time. These are things that are foundations to user research.
If you are trying to do a discovery, local government is always in a position where it is looking to make savings, when in fact, a discovery is typically needed to be paid for, to find out what those savings might be. So, it’s a bit of catch twenty-two in terms of what you can fund and what you can invest into to make those savings and gains later on.
The thing is, a lot of those digital savings can be hard to quantify but they are essential in that journey to delivering digital products.
Similarly, some of these service areas might have been burned by previous transformation promises. We’ve seen that where to improve systems, they can save some money by using less people. The people might get taken and moved, but the improvements don’t always materialise in the same way that they were expected to. That makes people reluctant to engage again.
This lack of user-centricity and focus can lead to services being ineffective, and not really based on real user feedback.
Number three, the final one on this half of the list is around legacy tech. Just to be clear here, I’m definitely not saying that councils are all still using typewriters or communicating in morse code. Well, not all of them. But occasionally councils can be hamstrung by legacy tech which is out of date and not conducive to modern software development practices. Sometimes small system tweaks can become big system changes, due to big dependencies on third parties. Maybe there are budget approvals and maybe there is the legacy tech and infrastructure that is slowing things down.
For some of the councils we have worked with, we have seen how difficult it can be to make a small change. Sometimes it’s just an iteration that’s needed, but the dependencies, the sign-offs, the multiple teams that are involved, that can all slow things down.
This is particularly a problem if councils want to move towards a more agile and nimble approach, where changes can be made more easily and rolled out without too many hoops to jump through. Therefore, getting the value to their users quicker. That is the thing that can be hampered with legacy tech in place.
For a while, some councils have been tied into long contracts with their partners and suppliers with tech that can’t be changed easily or integrated easily. It’s stuff that was built for requirements that are out of date. Now this thing needs to evolve in line with digital strategy, and the introduction of the latest technology for modern day development and modern-day software practices.
Three more on the challenge list before we move onto the next section. The first one here is not enough capacity or people. People being spread too thinly is a common one across all sectors, not just public. People being at capacity, there’s not enough staff. People often play multiple roles and are trying to juggle lots of priorities. I have worked with people that have a day job but are also filling in a product role or a developer role in the delivery team at the same time. Trying to do two full time jobs. Luckily people have been great at doing this juggling act, but the real impact of how much time and headspace that they need to give to a product and service that they need to own or work on versus their day-to-day duties and responsibilities.
There is a bad habit where people are overloaded with multiple, competing priorities. There’s a lack of capacity and of course that is a false economy. These are the things that will slow things down. You need to prioritise. We’ve all seen those articles and blogs about productivity and multitasking which give the same advice; prioritise and focus on one thing at a time.
Next one then, lack of collaboration. Less collaboration does equal more duplication of effort, more work across different councils. This can be down to a lack of understanding of the importance around collaboration between different teams within councils. Digital and tech teams need to play a big part in the procurement processes and the review and selection of different systems. This helps to avoid any pitfalls later down the line when you are integrating or utilising some of those offerings both from a technical integration perspective and also UX integration perspective. This lack of engagement or collaboration can also impact on how user-centred or problem-focused the decision process is, in selecting that.
Lots of smaller, more stand-alone councils have been working on solving the same problems that they are all facing. This is obviously inefficient and it’s not the best use of time or money. It means we will lose out on the efficiencies and benefits of creating a single solution that scales and works for all councils. Most councils will have some very similar or common sets of services that they need to be meeting through digital products. Why would we task every council in solving these themselves?
We have a couple of examples at Made Tech where we are looking at housing repairs and a couple of other systems that are common systems to councils. We are working with groups of councils who have initially thought to tackle these things themselves, and actually brought them together and increased that awareness of other solutions that other councils might have that can be reused, and other platforms that can be scaled across multiple councils.
The final one on this list of challenges with digital delivery in local government, is silo teams. Particularly making it difficult for end-to-end journeys to be transformed. It’s a common one, where we’ve got different service areas in a council all collectively responsible for an end-to-end journey.
Traditional governance and funding models mean that there is a discussion to be had about who pays for what and how much when it comes to digital products and services. The method of building also plays a part here. For example, taking a feature or product-based approach or a platform or component-based approach to the delivery. Each of those have a very different impact on how that delivery can go.
If the method spans different teams or service areas, then you’ve got a challenge of bringing everyone together and aligning them in a single direction. It’s not an easy thing to do when people are used to being in control of their respective areas.
Overall, a few key common challenges that we’ve experienced early on in projects within the local government space. Now we can run through some of the learnings and insights to minimise some of this friction.
If we just step through some of these, number one is lean agile delivery methods. Utilising these is really important to deliver value quickly. Utilising them is a given, really. Everyone knows about agile methods and delivery frameworks. We have all heard these terms, and everyone knows it is a good way to deliver, especially with digital products. Most people know that scrums are a good approach to take. Adopting an agile approach will help local authorities and others to build and release things quickly to the users.
What is more important though, in my opinion, is to focus on the agile principles and values more than the practices and the processes. A lot of organisations will prioritise the adoption of scrum or getting all the teams to start doing stand-ups for example or working in sprints. But if the core fundamentals of agile are not practised, then it does negate the need for agile frameworks. A core example of this is when we were working with Camden Council on a discovery for their online housing repairs service. After a quick and lean inception, a few meetings, and sessions early on, we decided that a combined discovery and alpha would be the best approach. Due to a limit on the budget, time, the need to get something functional and clickable in front of users and council staff as soon as possible.
We coined this project discovery to alpha and carried out some lean user research, as well as that technical analysis in the first few weeks. Covering clear needs, problems and pain points, we then took these learnings and fed them into the following few weeks of the alpha. Where we prototyped a new online journey.
We tested it with our users, validated the approach we were taking from the users’ and the design perspective. We then carried out some technical spikes and investigations to prove out the feasibility of this new journey.
Where typically a team might stick to the usual six-ish weeks for discovery and eight to twelve weeks for an alpha, and separate phases, we managed to combine the two into around eight to ten weeks. We narrowed the focus down to one key user journey throughout, just reporting repairs. Around 80 percent of the learnings and insights that we gathered will also apply to the other user journeys too.
Flexing the message and the approach here allowed us to deliver the right value, quicker. Albeit for a smaller scope, but with outputs that scale to the rest of their online journey in different user scenarios. Adapting methods but sticking to the values and principles is the key message on this one.
Collaboration, communication, continuous improvement are some of the most important aspects of software delivery. These need to be at the forefront of any council’s attempts to build digital products. Adopting the practices without these mean that people fall into old habits and will find it difficult to break free from the shackles of traditional reporting and governance methods.
Continuous improvement is possibly the most important aspect for any team. Reflection and iteration of the way in which we work, and how we are working, helps a team to get better, faster, more efficient, more effective at doing their job. Without this, a team will slowly fall behind the pace that is set in this digital age.
All of these aspects combined will help keep costs down and work as lean as possible, which is a nice segway into the next couple.
Maximising budget to make the small budget stretch further is a key one. It’s critical to make the budget for smaller councils go as far as possible. To do this, we have in the past had to get creative about different roles and responsibilities and different methods. For example, with one council, for an alpha stage, we focused on building a proof of concept which was essentially the first iteration of the product. This was literally the skeleton application for the product.
We also used this as the platform for the user testing sessions throughout as well. So rather than spending time building a clickable prototype in Axure, for example, which obviously has its benefits in other scenarios, we focused efforts on a functional code-based app that basically hit two birds with one stone.
This makes for a better use of the budget in this scenario that we had, where it was limited. It ensured that the budget stretched as far as possible because we were building that application, iteration on it and user-testing on that same platform as well. So, it was evolving and changing shape and getting validated much more quickly throughout that process.
Number three then, we’ve got collaborate and re-use. Combating the challenges of duplication of work across councils, collaboration and consulting is a great strategy that is out there, and it is something that we have adopted as well.
Open sourcing some of the common components or platforms allows teams and minds to contribute to the evolution of digital products which makes it better and more refined than it otherwise would have been.
Regarding collaboration across councils, to help with this, we have set up communities or practitioners groups, in this case for housing repairs. We work with multiple councils to deploy our own user-validated service to them, which makes it quicker, easier, and cheaper than them building from scratch. That re-use is so important because it gives them all the features they ever wanted from a housing repair service. There were some additional things about getting it tailored and fully integrated for each individual organisation but this gets them at least 80 percent of the way there.
These councils can also contribute to it, they can shape the future direction of the service, which ensure that it will meet all of the needs and deliver value to their users. It’s been a really good method, to increase that collaboration across councils. It is proving the reusability of platforms and adopting an open source approach where the code is publicly accessible.
On the flipside, collaboration across internal teams is also something that is not as easy as it seems. Teams are busy, people have their day jobs. What we’ve done in the past is use focused working sessions and pairing opportunities, to help to get the most out of the time available in that collaboration space.
We have also attempted to bring people together from different teams into small, autonomous teams temporarily. This temporary nature helps to bypass a feeling of reluctance when it comes to moving teams or roles. When it is framed as a temporary trial or a pilot, people are a bit more willing to give it a go. Typically, in the past we have experienced and seen that they have ended up really enjoying that change as well.
Number four, focus on the user needs, and prioritise. Something that really helped on that discovery to alpha that I mentioned is that the priority for the client side is to be really good at relentless prioritisation based on user insight. So, any new request, feature or problem that came through was prioritised against the rest of the backlog. This meant that we were always laser-focused on the most important thing at any one time. It allowed us to get the core functionality of the new journey built, deployed, and delivered, staying true to one of the agile principles, which is working software being the primary measure of progress.
This really helps where there are people being spread too thin, and there are multiple priorities and the capacity is limited because prioritising the backlog and the tasks helps to focus people’s efforts and attention where there are these competing priorities.
It helps ensure that the whole team are focused on the same thing, rather than being pulled in slightly different directions and working on slightly different things. For example, the developers and designers as a team, all working on the same story and the same functional area, rather than working on separate things.
Number five; building and educating people along the journey. Often, we have come across teams who need support and upskilling to improve their awareness of discoveries and user-centred design methods. Just not having had exposure to these modern ways of working can limit how much time and effort is invested upfront, due to a lack of experience and expertise. It’s a circumstantial thing. As I mentioned earlier, key challenges are where teams don’t get the importance of user research and agile ways of working. Training, upskilling, mentoring, and coaching, all of these things will help build their own capabilities and skillsets. This will also help to ensure that services are built as GDS compliant and in line with all their service standards as set by GDS.
Incorporating these from the discovery all the way to delivery is key to enabling a successful delivery. It also helps add a bit of structure and is a really good guide to teams who are new to these ways of working, and a really good reference point.
Build and define; defining the vision, purpose and goals that are being set out to achieve, and aligning everyone behind them brings real clarity to the direction of the product or service, and help to define the success metrics and measures.
Two of the smaller clients that we’ve worked with, a couple of other councils, we spent some time pre-delivery to help build that buy-in and win the hearts and minds of the stakeholder group that were involved. We set up a few sessions to make sure everyone was on the same page. This made the delivery that followed much more successful, more streamlined, more seamless because we had built that buy-in up front.
Number six on this list, piloting a small-scale experiment, and taking this experimentation mindset into your delivery. Taking a key problem area, spinning up a small team with the right skills, support, and processes to tackle that problem, and just seeing what happens when they have the right empowerment and environment to thrive. This breaks down barriers, it helps to remove those silos that we mentioned earlier as one of the key challenges. In these organisations, there is years and years of structure that has been built up. Teams of people are used to working in their own teams and their silos. They are not so used to working in small, cross-functional teams. To move from one to the other can seem like a daunting task like any change but framing it as a pilot or an experiment of a new collaborative way of working makes it easier for people to take that first step.
When working with local authorities, we are always trying to make sure that we discuss the roles, the expectations up front, to make sure we are able to work together as one single team, rather than silo teams with barriers. It also allows you to trial new delivery methods and techniques which an organisation might otherwise have been reluctant to try in their old structures and old models. Giving the team space to innovate and solve problems in the best way possible both in terms of what they are building and also how they are building.
To summarise, there are a multitude of challenges across these organisations, across digital delivery in local government. Some of them are more prominent in local government due to some of the factors and reasons that we have covered off today. We will also talk through some of the learnings and experiences that can help overcome these challenges with what is available.
There are a few methods and approaches that can remove these blockers and enable rapid, lean, digital delivery of products and services.
Here are the key principles to take away for a frictionless digital delivery in local government. On the top left, we’ve got agile principles over practices. Prioritising principles over the prescribed practices. Prescribing agile practices such as scrum framework, maybe even a GDS phases or Canva methods for example are great structures for learning how to deliver in an agile way.
They teach really good behaviours, the right activities that are needed when teams are new to agile ways of working. However, try not to get constrained by technical methods. Don’t take into account any context you are in. Remember my example earlier about combined discovery and alpha where we tailored and evolved a few approaches to come up with an effective method that allowed us to deliver on our own outcomes with the council. Sticking to the principles of things like collaboration, quality, focusing on working software and user satisfaction.
Then top right we’ve got be lean, one of the agile principles is simplicity, the art of maximising the work not done. For me, you’ve got to apply this mindset to the outcomes, the outputs, and the methods. Taking an NVP or a lean approach to all of these things.
Collaborating across teams and councils to save that time and share knowledge. Re-using work that is already done, saving time, saving money, and delivering value quickly when you are re-using work.
Experimenting and trialling things to get validatory feedback on the direction that you are taking with your product. Making sure that your product is more refined, validated, and accurate by the time you get to deployment and getting that out to real users.
Bottom right, we’ve got bringing everyone along for the journey. So, bringing everyone on the ride with building that buy-in, educating and coaching along the way. These are all key methods to ensure that you have got everyone on board.
Utilising different methods to do this; open show and tells, sending out week notes regularly, blogging about what you’re doing, socialising the work that has been done, working in the open to increase visibility and transparency. This not only helps people to understand but it also encourages more interaction, more feedback, more healthy debate. Which ultimately does create a more refined product or service due to that healthy debate, challenge, and discussion throughout.
Finally on principles; putting yourself in the user’s shoes. We know the importance of user feedback and user-centred design methods. These are critical in local government, as with any digital delivery. To not only validate the product but to break down the barriers and silos which can be present in local government. There’s no argument and no discussion point when it comes to the fact of what users say in the feedback. So, prioritising user research, testing and feedback regularly throughout the whole delivery process will ensure that the end result and the end outcome is accurate and successful, fulfilling the original need or problem area.
Some teams will perform some of that research up front but then drop it later on, but it’s clear that you need to continue this throughout to de-risk the chance of it not fully meeting user needs. Make sure that is validated all the way through to the end.
These are the key principles to keep in mind when delivering digital services in local government in a lean, agile, and rapid way. Hopefully, these will help drive the right behaviours and actions that are needed to make it a success.
At that point I just want to say thank you so much for listening to me, I really appreciate your time. I am going to be happy to take any questions, or feel free to get in touch with me after today’s talk too. Thank you very much, I will hand back over to Lucy.
LUCY WAKEFORD: Excellent, thank you so much, Anikh, for that insightful presentation. It has been really interesting to hear some of your learning and expertise. Thanks so much.
We do now have time for some questions. There are a couple that have been sent through, but as I mentioned, if you do have a question, please send that through now on the Q & A tab. Otherwise you will have an opportunity to carry on the conversation later at week.digileaders.com.
I’ve got a question here. “Would you consider the existing staff lack of knowledge and training on new ways of working a challenge? How do we change this, and what could be the easiest way to get them up to speed?”
ANIKH SUBHAN: Yes, that’s an interesting one. It is definitely a challenge, but it is circumstantial. Some people might just not have had the opportunity to work in agile methods before. The way to change this from experience, is to take the time to train and coach teams and people. Really spending time with them, sitting down with them, and understanding where they are coming from. Also, learning through doing. Taking the time to do that upskilling but giving a space to do the job and learn through doing. Creating an environment that is psychologically safe is something that allows for the experimentation that I mentioned at the end there. And any failure and learning from that failure is really key.
So, a mixture of that and pairing and shadowing other teams is a really good, quick way to learn new ways of working. A mixture of some of those techniques.
LUCY WAKEFORD: Great, thanks. There is another question here. “Are there any lessons or shared knowledge from central government that could apply or be worked on for local government?”
ANIKH SUBHAN: Yes, aside from having maybe slightly more budget and access to more skills and resources, and clearly more people. The key thing is that you are focusing on what you have got available to you. There are lots of different scenarios and different circumstances here. Trying to achieve the outcomes with what you’ve got available to you, and adjusting the scope and plan accordingly, having that mindset coming into it, is probably the biggest lesson or knowledge that can be shared.
This goes back to one of the other things I mentioned. Having a plan is really important. It’s important to have that in place and for that to set the direction for the product and for the team. But adapting a plan is more important. Based on the constraints that you have, what can you do to adjust the scope, what can you do to adjust the priorities? What can you do to make sure that the outcomes are still met, but maybe in a slightly different way?
It’s about adapting and tweaking that plan.
LUCY WAKEFORD: Excellent, thank you. There is a question here from James. “How similar are the services being offered by different local government organisations? Presumably, there is much more similarity than between central government departments?”
ANIKH SUBHAN: Yes, absolutely, thanks James. Yes, a really interesting point. There is a lot of similarity and we’ve seen across some of the councils we are working with, a huge amount of commonality in what they are trying to do and the service they are trying to build and deliver. There is a lot of the same stuff in different councils, the different services that are needed. Waste management for example, or library services or housing repairs. There are ways to make sure this is done in an efficient, scalable way, and that is what we are starting to do, and really starting an online journey to do.
There are obviously elements of things that need to be tailored and customised for each individual council based on the technical integrations that they have in place, the specific requirements and needs based on the context of that particular council. But these are things that can be taken into account with a core platform with a core set of components and services.
So yes, a huge amount of commonality and similarity across these councils. It’s about how we meet as much as that as possible with common stuff and reusable and shared stuff, but then give them the opportunity to tailor that for themselves, as well.
LUCY WAKEFORD: Thanks James, great question. There’s another question here. “Having in mind the wide range of individual organisations in local government, what are the anticipated challenges in embedding an agile culture?”
ANIKH SUBHAN: Yes, another really interesting and valid one, actually. There is always that reluctance to change or engage with a new way of working. Down to the fear of the unknown and also being burned from the past, and ineffective changes that have been attempted.
There is also the perceived cost of change. Although it is more efficient in the long run, that needs to be taken into account.
A previous talk of mine around common challenges in agile transformation, we talk about exactly this, and why it’s not a change project but more an evolution of practices and behaviours over time. With any change, taking into account each organisation’s perspectives and requirements, changing their ways of working with that in mind will help to drive those changes from their point of view.
It’s very much about getting into their shoes, understanding the needs that they have for that way of working and why they want to change and embed that sort of agile culture, and make sure they are doing it for the right reasons, not just because you want to be agile, but actually there are some things and outcomes that you want to see and achieve from that.
LUCY WAKEFORD: Excellent, thank you. Anikh, do you have any final thoughts that you want to share before we end the webinar?
ANIKH SUBHAN: No real final thoughts apart from those key principles and takeaways. Other than just to say thank you very much and please do get in touch with any questions or discussion points you’ve got after today’s talk or if you are watching the recording back. Get in touch, give us a shout and we can always discuss things at a later date.
LUCY WAKEFORD: Excellent, thank you so much and thank you everyone so much for tuning in. Thank you so much to Anikh for such an interesting and informative session.
A recording of this will be on week.digileaders.com on the same talk page that you registered on. You will also be emailed a link to the recording later on today. You can share that link with colleagues and watch it back at your leisure.
Thank you so much again and we hope to see you all soon.
~ End of Recording ~
Back to the episode
