Hosted by Gavin Freeguard, Director, State of the Future. Peter Thomas, Director of civilservicereformuk.com, on 'What 15 years of GDS tell us about successful…

Hosted by Gavin Freeguard, Director, State of the Future. Peter Thomas, Director of civilservicereformuk.com, on 'What 15 years of GDS tell us about successful…

CustomerFirst shares early lessons from its work with the Driver and Vehicle Licensing Agency (DVLA).

Technical Websites builds high-performing websites for Holiday Parks, Restaurants, Ecommerce, Trades, Corporate businesses and more. UK-based, built to convert.

Technical Websites builds high-performing websites for Holiday Parks, Restaurants, Ecommerce, Trades, Corporate businesses and more. UK-based, built to convert.

CustomerFirst is a new unit within GDS learning what conditions help transformation teams succeed through a NewCo approach. Our first partnership is with the Driver and Vehicle Licensing Agency 's (DVLA) Drivers Medical service, which makes licensing decisions when a medical condition may affect someone's ability to drive, with consequences for people's independence, work and everyday life. When we formed the joint DVLA and CustomerFirst team and began looking at the Drivers Medical service, we were also testing what conditions a NewCo approach requires: creating enough space around the team to pursue change, identify the constraints holding the service back and learn which freedoms actually matter. In practice, that space is shaped by the organisation around the team because Drivers Medical cannot pause while we change it. Licensing decisions carry on being made every day, established processes still shape how they are made, and people carry years of knowledge about why the service works as it does. So, the way the team is set up, and the support around it, must respond to that context as much as to the methods the team uses. We are still learning what those conditions need to be. Some of the choices we made at the beginning have already proved particularly important. ## **Create real capacity for the work** Before delivery began, senior stakeholders across DVLA and GDS agreed a commitment to a shared ambition for the transformation work and to protecting the conditions the team would need to pursue it. Creating dedicated capacity was part of that agreement. Drivers Medical colleagues joining the joint team came out of their existing roles, with those roles backfilled, so they could work full-time alongside GDS colleagues. Backfilling sounds like a resourcing detail, but it changes the relationship people have with the work. Transformation asks people to spend time understanding a problem, following evidence, testing ideas and making decisions together. That becomes much harder when the same people remain responsible for keeping their previous part of the organisation running. Giving people real capacity has helped us build a joint team rather than two organisations collaborating around the edges of existing jobs. Relationships have developed through the work itself, and responsibility for where the work goes is shared. For us this has become one of the clearest NewCo conditions: enough protected capacity to organise around the service problem, rather than being repeatedly pulled back into responsibilities people already hold. ## **Bring organisational knowledge into the team** The people who know the existing organisation best are also some of the people best placed to help change it. Drivers Medical colleagues understand why processes exist, how systems depend on one another, where previous attempts have struggled, and which apparent constraints may have more room to move than they first seem. That knowledge is difficult to reproduce through stakeholder interviews or occasional governance meetings because much of it sits in experience, relationships and practical judgement. The value becomes clearer when the team starts trying things. An experiment may run into a technology constraint that has been treated as fixed for years. A different service model can surface questions about assurance, information governance or policy. Sometimes the team discovers that a constraint is protecting something important. Sometimes it finds an existing arrangement that can be approached differently. Having that organisational knowledge inside the team helps us understand what we are dealing with before deciding what needs to happen next. ## **Work in the open, and know where authority sits** Working in the open is part of how we manage the boundary between decisions the team can make and those that need authority elsewhere. We share work and thinking early, so people around it can see what is changing and challenge it where useful. Visibility does not automatically create another approval step. Small tests give the team something concrete to decide against, reducing how much depends on assertion or hierarchy and keeping decisions close to the people doing the work. When something does need authority elsewhere, the partnership gives us a route to senior sponsorship. We call this "air cover". Leaders have already committed to the conditions around the work, so escalation is about unblocking rather than re-stating the case. The judgement about when to use it matters. Escalating too quickly moves decisions away from the people closest to the work and turns senior sponsorship into part of the everyday operating model. Each constraint we hit is useful information either way. It tells us where authority sits now, which decisions the team can make for itself, and where a wider organisational change may eventually be needed. For small experiments, the team works with assurance specialists to identify an approach that reflects the scale and nature of the risk. That keeps the team moving safely. It also shows us whether the existing assurance route fits this kind of work, and whether a constraint genuinely needs air cover or can be worked through within the team's own authority. ## **Learning what NewCo needs through delivery** We are still early in this work, and part of the NewCo hypothesis is that we should learn the operating model through delivery. Understanding why a constraint exists, what it is protecting and how fixed it really is can tell us as much as successfully removing it. So far, three conditions have proved particularly important: creating real capacity for transformation work, bringing organisational knowledge into the team, and working in the open with clear routes for decision-making. These are conditions we would encourage other organisations to consider when setting up transformation work of their own. As the work grows, we will keep testing where those boundaries need to sit and which of these conditions transfer to other transformation work across government. If you are working through similar questions elsewhere in government, we would be interested to hear what you are learning too. You can contact the CustomerFirst team at customer.first@dsit.gov.uk.

Most tech companies quietly absorbed tariff costs from consumers - until Panic Inc. decided differently. In a bold move, the indie developer behind Playdate handheld announced they're refunding tariff fees directly to customers who paid them during the Trump trade war. This isn't just good PR - it's a masterclass in brand loyalty. When tariffs inflated graphics-card prices for handhelds, Panic chose to refund instead of passing the cost on. It reflects their design philosophy of transparency. Major brands bake tariffs into permanent price lists, but Panic treats refunds as a fiduciary duty. This shows ethical supply chains can be a competitive edge. For Playdate owners it's a reward for early support. For the industry, it demonstrates that surviving future trade wars requires prioritizing customers. Don't miss this game-changing decision! Tools used for generation Text Gemini Narator Azure TTS Clips Pexel Rendering Remotion

## Why architecture became about people, not technology When we started building the technology and architecture practice for CustomerFirst, we thought we had a reasonable idea of the role architecture would play. Like many teams, we expected to spend our time understanding technology estates, mapping systems, identifying technical risks and leading organisations towards making good technology decisions. What we did not expect was that the most valuable architectural conversations would have very little to do with technology at all. Instead, we've found ourselves talking about organisations, relationships and trust. We've spent time understanding how decisions are really made, where operational boundaries exist, and how information moves between teams. We’ve also explored why seemingly simple changes can become surprisingly difficult. As we've worked with different organisations, we've realised these themes aren't unique to one partner. They've appeared repeatedly across services and departments, changing the way we're thinking about architecture. Before committing to significant investment or large-scale transformation, we work with organisations to understand whether a different approach is actually viable. We test ideas, gather evidence and learn quickly before deciding what should happen next; we’ve previously written about our approach to exploration sprints. We're also learning what it takes for multidisciplinary teams to succeed in the NewCo model, and architecture needs to fit that environment. As we've written before, NewCo is about creating bounded space for small, multidisciplinary teams to look at a service differently. Many architectural approaches were developed for delivery programmes that already knew where they were heading. We're often working with organisations that are still defining the problem, or where the problem itself has evolved. They're exploring options rather than implementing predetermined answers, which has prompted us to rethink architecture's role in delivery. If understanding the landscape takes months, teams lose the ability to learn quickly. If decisions have to pass through layers of governance, momentum fades and support for change becomes harder to build. None of this invalidates traditional approaches to enterprise architecture. It simply reflects the context it was designed for. We're finding ourselves applying architecture differently. ## What we mean by lightweight architecture We've started referring to this as _lightweight architecture_. This is not because it reduces the rigour required to meet core principles of scalability, secure by design, interoperability or maintainability. It’s because it applies just enough architectural thinking to help teams make the next good decision. Rather than answering every question up front, it helps teams move forward with confidence while leaving room for new evidence to influence future decisions. ## What we learned from two recent engagements During a recent six-week discovery, we worked across an extremely fragmented and complex federated landscape. At the outset we expected much of the work to be on technology and integration, to understand the systems, the dependencies and how everything connected. We quickly discovered that understanding the technology was only one part of the challenge. The more important learning was understanding the landscape around it: who owned what, where decisions were made, how change happened and what would need to be true for services to evolve safely. Users in this context do not experience those organisational boundaries; they experience a moment as part of their wider journey across that complex system. That observation changed the conversations we were having. We spent less time discussing integration patterns and more time building a shared understanding of the problem, identifying operational dependencies and exploring how information could be shared responsibly. These conversations were every bit as architectural as discussing platforms or APIs. One of the most valuable architectural decisions we made on another engagement was not deciding what to build. It was deciding not to build at all. Instead of investing immediately in technology, we created a small experiment that generated evidence within days. The experiment was simple to implement, however went through a fast-tracked but fully signed-off governance process to get the experiment safely in front of users. We worked with the Data Protection Officer as part of the delivery loop rather than as an approval gate. By giving them early access to the architectural decisions they were quickly able to assess risk and resolve privacy concerns that needed assurance before launch and within the scope of the experiment. We used existing products that have been built and exist in the GDS products suite. We obtained approval to divert a small segment of user data that flowed into the service for a particular cohort of users. We used technical expertise from the partner organisation to route the cohort to the new service and worked with content designers so the new service could be found by that group during the experiment. That evidence is now shaping future decisions in a way that simply would not have happened had we started with a detailed solution and spent weeks or even months working through governance processes designed for larger-scale change. We know governance systems exist to reduce risk in delivery. We are testing the application of appropriate governance at varying stages of our work, which is important, especially as we move towards higher fidelity, where more governance and assessment will always be necessary. ## Reducing the cost of discovering the future Experiencing high governance environments has reinforced something we'd started to suspect across several explorations: perhaps one of the most valuable things architecture can do is not describe the future but reduce the cost to the taxpayer of discovering the future. That idea continues to shape our thinking. We're not presenting lightweight architecture as a finished methodology or a replacement for established architectural practices. But the faster organisations need to learn, the more architecture itself needs to become adaptive. For us, that means architecture becoming another enabling function within the CustomerFirst model. It helps teams understand before they invest, helps partners work before they integrate, and helps organisations make confident decisions while uncertainty still exists.