What does a typical morning look like? 

There is never really a typical morning for us, each week there’s a new exciting project, whether it’s with the DfE, coding alongside apprentices or even writing blogs like this one! But even with the change in tasks, most mornings start with a quick meeting with our supervisor, Dom.  Before we jump straight into work, we usually play a short game together to get settled and make the rest of the day feel a bit lighter. It’s a nice way to ease into the work. 

After the game, we have a catch-up session on what we did the previous week and what awaits us in the following week. It is also recommended to take lots of breaks throughout the day. I then spend some time writing in my journal. This is where we reflect on what we did that week, what we learned, what we want to learn next, and any worries or concerns we may have. This helps me keep track of my progress and reflect on it as part of my development. 

What was the most surprising thing you learned about working in tech? 

The most surprising thing for me was how collaborative everything is, not just sitting at a chair doing independent work that drains the life out of you, but instead, I find myself constantly pairing up on code and discussing ideas. This opened my eyes to how much I misunderstood what tech is; it isn’t just about writing a bunch of code, it’s communicating with others and solving problems together. 

Whilst working on my project of designing and building a simple assessment system for teachers, I realised I wasn’t just learning HTML, CSS, Flask or SQL, I was learning what it’s really like in a junior product designer’s shoes. I was able to pick up on what the user wants/needs to ensure a smoother user experience for a non-technical audience.  

What advice would you give to the next group of students? 

My advice is to find a routine that works best for you. Both college work and  your responsibilities tend to pile up quickly, making you feel overwhelmed.  If you can’t manage your time well, then try different ways to see what fits you. And honestly, if u end up doing things last minute (not recommended,  but we’ve all been there), make sure you still try your best.

The post A day in the life of a T-level student – Taybah appeared first on Made Tech.

Spend any time inside a policing or justice organisation and you start to see the same patterns. People switch between systems, copy information from one place to another, and rely on spreadsheets just to build a complete picture. None of it feels deliberate, but it has quietly become the way work gets done.

That is what technical debt looks like in practice. It is not an abstract IT issue, but something that shapes the working day and slows people down. In already stretched environments, that friction quickly becomes a real problem.

The instinct, when things get this tangled, is to start again. Replace the systems, wipe the slate clean, and build something new. It sounds decisive, but it is rarely the safest or most effective option.

In many cases, the better approach is more measured. Modernisation does not have to mean starting from scratch, and new does not automatically mean better. The organisations seeing the most success are often the ones improving what they already have, rather than replacing it wholesale.

What technical debt really looks like

Ask people to define technical debt and you will get a range of answers, but Ben Pirt, Principal Technologist at Made Tech, puts it simply. “It ultimately just looks like code that you can’t really maintain. Once systems reach that point, everything becomes harder, from making small changes to finding people who understand how things work.”

Ben adds: “What is often overlooked is that age is not the only factor. Some systems have been running for decades, while others are only a few years old but already difficult to work with.

“I think the issue comes from neglect, whether that’s over a long or short timescale. Most systems were built with good intentions, but as standards move on and expectations change, they are not always updated to keep pace. Over time, they drift further away from what users actually need.”

Where legacy systems hit hardest

That gap tends to show up most clearly in frontline roles. Geraldine Mathews, Made Tech’s Client Partner, describes environments where caseworkers move constantly between systems that were never designed to work together. Each system does its own job, but there is no single view, so people are forced to piece information together themselves.

“If you wanted to know one thing, you logged into that system. For something else, you logged into another, and never the two should meet. The result is duplication, repetition and a steady loss of time. Users just want IT to work for them, be intuitive and solve the whole problem,  often in difficult and complex situations.”

Geraldine continues: “They really just want to be sitting down, looking someone in the eye. IT should support that work, not take time away from it.”

Part of the reason this situation develops is structural. In the commercial world, products improve because organisations compete for users. In government, internal systems do not face that same pressure, so once they are delivered, they can remain unchanged for years.

“They’ve got to be maintained,” Ben explains. “Without that natural incentive to evolve, systems tend to stagnate. Over time, workarounds build up and the gap between what the system does and what users need continues to grow.”

Why evolution beats replacement

At that point, a full rewrite can seem like the obvious answer. It offers the promise of a clean start and a chance to fix everything in one go. In reality, it introduces significant risk, especially when the existing system is still handling critical work.

There is also the challenge of understanding what the system actually does. In many cases, documentation is limited and knowledge has moved on. Switching everything off and replacing it in one step leaves very little room for learning or adjustment.

A more practical approach is to evolve the system in place. That does not mean preserving everything, but it does mean understanding it properly before making changes. As Ben puts it, “It’s not a legacy IT problem,” and starting with technology alone misses the point.

The first step is to understand how people use the system today and where it causes friction. That means combining technical analysis with user research and service design. Only then does it make sense to decide what needs to change and how to change it.

Reducing risk without stopping the service

Risk is always part of the conversation, especially in services that handle large volumes of sensitive data. The way change is delivered makes a big difference here. Incremental approaches allow teams to test, learn and adjust before committing fully.

Ben describes work on a system where the team analysed existing behaviour, then tested a new version against real data. They ran both systems in parallel and gradually shifted usage across, monitoring the results as they went.

“We compared it against millions of real examples,” he says. “In some cases, we even discovered issues in the original system that had gone unnoticed.” The transition itself was so smooth that “no one noticed”, which is often the best possible outcome.

This approach also brings users into the process earlier. Instead of delivering something new at the end of a long project, teams can show progress as they go and gather feedback along the way. That creates a stronger sense of ownership and improves adoption.

For people who have used the same systems for years without being consulted, being involved makes a real difference. It turns change into something they are part of, rather than something that happens to them.

Dealing with uncertainty

One of the challenges with this kind of work is uncertainty. Legacy systems often contain hidden dependencies and behaviours that only become visible once you start digging into them. That can make it difficult to define exact timelines and costs upfront.

“There are huge amounts of unknowns,” Ben says. “The most effective projects tend to acknowledge that reality rather than trying to plan around it. They rely on experienced teams who can adapt as new information emerges.”

There is also a growing recognition that technical debt is not just an operational issue. As systems age, they can introduce security risks as well. The longer technical debt is ignored, the harder it becomes to address. What starts as an inconvenience can gradually turn into a barrier to change and, in some cases, a source of real risk.

This all points towards a more balanced view of modernisation. It is not about defending legacy systems, but it is not about discarding them either. The goal is to improve what exists in a way that is controlled, sustainable and grounded in real needs.

That approach can reduce costs by extending the life of existing systems, while improving performance where it matters most. It also lowers risk by avoiding disruptive, all-or-nothing change.

For organisations working in policing, justice and across government, that is often the more responsible path. It delivers progress without unnecessary upheaval, and it keeps the focus where it belongs, which is on the people using these systems every day.

Learn more about our public safety and defence expertise and how Made Tech can help your organisation.

The post Modernising the legacy estate: reducing technical debt without starting from scratch appeared first on Made Tech.

Phase 2 is coming later in 2026. And it’s going to be harder.

Not just because there are more hazard categories. But because the nature of those hazards means the way providers have to respond is fundamentally different. The teams involved, the processes required, and the decisions that need to be made won’t map neatly onto anything most housing organisations already have in place.

Here’s what you need to know.

What is Awaab’s Law?

Awaab’s Law was introduced through the Social Housing (Regulation) Act 2023 following the death of two-year-old Awaab Ishak from prolonged mould exposure.

The regulations require landlords to investigate hazards in their tenants’ homes, provide written updates,  and commence any required follow-on works within strict timeframes.

Phase 1 brought damp and mould, and emergency hazards into scope. For emergency hazards, most providers already had a process of sorts – typically an emergency “make-safe” process. Phase 1 largely added formal timeframes and documentation obligations around something that already existed (to a greater or lesser extent – depending on the provider) 

Phase 2 extends those same obligations to a wider set of hazard categories from the Housing Health and Safety Rating System (HHSRS). A firm implementation date has not yet been confirmed – it is subject to secondary legislation – but government guidance points to later this year. Phase 3, covering the remaining HHSRS hazards, follows in 2027.

Which hazards does Phase 2 cover?

What Phase 2 means for social landlords

1. The admin burden is going to get heavier

The government estimated that Phase 1 would cost the social housing sector £129 million in additional staffing alone. When providers were consulted on whether that figure was accurate, 63% said it was an underestimate.

That’s before Phase 2 adds five new hazard categories to the workload.

Providers who have found Phase 1 stretching their capacity are about to take on more work. For each of these new hazard categories, the same work is required: investigations actioned and recorded, timeline documentation, written tenant communication, and remediation planning.

The Housing Ombudsman’s caseload tells the same story. Determinations rose 30% in 2024-25, and over 40% of all compensation ordered that year related to failures around damp and mould – hazards that have been in scope for years. If the sector is still struggling with the original obligations, adding five more hazard categories without a step-change in how cases are managed will only make the situation worse.

If you’re already feeling the weight of Phase 1 compliance, Phase 2 doesn’t give you breathing room. It raises the floor.

2. These hazards aren’t all your repairs team’s problem

Damp and mould – however complex – is something most repairs and maintenance teams had some version of a process for. There were SLAs. There were contractor relationships. There was at least a general sense of who owned it.

Excess cold, structural instability, domestic hygiene failures – these don’t sit cleanly in a repairs workflow. They’re more likely to land with building safety teams, compliance functions, or neighbourhood and housing offices. Some will require specialist contractors. 

The people who got your social landlord through Phase 1 may not be the right people for Phase 2. And the people who are the right people may not know that yet.

3. Preparing for Phase 2 needs an operational owner

The cross-functional nature of Phase 2 means the preparation work doesn’t belong to any one team by default. Designing a process that spans repairs, building safety, compliance, neighbourhood housing, and specialist contractors — and then standing it up so it actually runs — is a substantial piece of work in its own right.

It needs someone who owns it. Not governance oversight. A named lead whose job is to design the process, get the right people across it, and make sure it runs consistently once Phase 2 lands.

Without that, the reality is you’ll find yourself trying to pull it all together at the last minute. Processes that haven’t been properly designed. Teams that haven’t been properly briefed. Cases that fall through the gaps because nobody agreed who was responsible.

With Phase 2 adding five new hazard categories, there are simply more things that can slip. More places where an unclear process means a missed deadline. More cases where the wrong team owns the response — or nobody does.

Phase 2 is more complex than Phase 1. The cost of not having a clear owner this time is higher.

4. You’ll need policies that might not exist yet

Some of the hazards in Phase 2 will force decisions that providers haven’t had to make at scale before.

The most significant is relocation. When a property is assessed as presenting a serious risk from excess cold, structural instability, or fire, what happens to the tenant? What are your criteria for a temporary move? What’s the process for managing that, communicating it, and evidencing it?

At the volume that Phase 2 is likely to generate, an improvised approach won’t hold.

What to do before Phase 2 arrives

You don’t need to wait for a confirmed implementation date to start preparing. The hazards are known. The direction is set. Here’s where to focus now:

• Audit your team structure. For each Phase 2 hazard category, who in your organisation would own the response? Is that clear? Do they know?
• Identify your process gaps. Where Phase 1 required you to build a new process, Phase 2 will require more. Map what you have. Name what you don’t.
• Define your relocation criteria. Don’t leave this until a case forces the issue. A short internal policy – what triggers a relocation, how it’s approved, and how it’s documented – will save significant time and protect you legally.
• Assign a programme lead. Ideally, someone with the authority to convene the right teams and the mandate to make process decisions.

How Made Tech’s case management software helps

The thread running through all of this is coordination. Phase 2 compliance isn’t just an operational challenge – it’s an organisational one. The right people need to know what they’re responsible for. Cases need to be tracked across teams and contractors. Deadlines need to be visible. Evidence needs to be captured consistently.

Our Hazard Case Management software is built for exactly this. It gives housing providers a single place to manage hazard cases from ‘becoming aware’ through to resolution – tracking deadlines, coordinating across teams, capturing tenant communication, and generating the audit trail that Awaab’s Law requires. It integrates with existing housing management and repairs systems, or works standalone.

If you’re thinking about how to get your organisation ready for Phase 2, we’d be happy to show you what that looks like in practice and share what we’ve learnt from phase 1. 

The post Awaab’s Law Phase 2: What it covers and what housing providers should be doing now appeared first on Made Tech.

This post is part of our Delivering Public Safety Outcomes at Pace series.

A few standout digital services have changed what people expect from technology. Whether that’s Uber reducing the friction of booking a ride, Netflix recommending the next big Korean hit or Amazon recommending the must-have accessory to complement your last purchase, today’s digital world feels simple and intuitive.

Once people get used to that kind of experience, it quickly becomes the benchmark for everything else they use and public services are no exception.

For teams delivering vital services, that shift in expectation creates a difficult balance. Citizens and businesses want services that feel quick and easy to use. At the same time, public sector delivery sits alongside policy requirements, operational realities and tight budgets. According to Sarah Ward, Delivery Director at Made Tech, designing around user needs is not about ignoring those constraints, but is about navigating them carefully while still building something people will actually use.

User needs meet policy and operational reality

One of the biggest challenges is often cultural rather than technical. Many public sector organisations still carry the memory of large IT programmes that ran over budget or failed to deliver what they promised. Those experiences continue to shape how new services are approached today.

“Our customers are still scarred by decades of IT delivery challenges,” Sarah says. “They still struggle with the concept of a minimum viable product that is then iteratively delivered and improved.”

Launching something that is not yet fully complete can feel risky in that environment, particularly when funding cycles are structured around fixed annual budgets. Departments worry that if something launches unfinished, the money will disappear and they will be left with a half-built system. The key, however, is to consistently build and demonstrate the value creation that the product and service bring to citizens.

James West, Made Tech’s Industry Director for Public Safety, Security and Defence, believes part of the answer lies in rethinking how digital services are viewed in the first place. “Too often services are treated as large, one-off programmes rather than products that evolve,” he says. “The service design and the product you build are never finished. Ultimately, you’re balancing the needs of citizens, what the service users need and what government can actually afford. These decisions continuously change over time, and that is right.”

That balancing act is the inflection point where many of the real delivery decisions happen. Policy teams may define the outcome they want to achieve, but translating that into a service that works for real users requires constant adjustment. James argues that the traditional model, where policy defines the requirements and then hands them over to delivery teams, often creates friction.

“Policy do their bit, then they fence it over to delivery,” James says. “And there’s a constant to and fro between the two sides.”

For James, the answer is not more process but closer collaboration, with digital thinking embedded much earlier in policy design.

Why early delivery matters

Even when teams agree on the approach, releasing something early can feel uncomfortable. Sarah recalls one project where an organisation agreed to launch a new digital service even though it did not yet match every feature of the system it was replacing.

“I think trust is huge,” Sarah says. “That’s the only way we got through it.”

The decision was not universally popular. As feedback started coming in, stakeholders questioned whether the organisation had moved too quickly.

“They did wobble,” Sarah says. “They nearly rolled back because they didn’t like the negative feedback. This is where experience, guidance and trust with proven operators really come to the fore.”

But launching early also revealed something not highlighted during user research. Once users started interacting with the service, one request kept appearing in the feedback.

“One of the things users really valued was widgets on their phone,” Sarah explains. “That hadn’t come up in any of the research we’d done.”

Because the service had been released to a small group first, the team could respond quickly. The team built a simple widget over a short sprint cycle and released it before the full rollout.

“That’s the value of launching early,” Sarah says. “If we’d waited, we wouldn’t have known.”

For James, examples like this illustrate why approaching programmes differently enables success. “When projects become too big – or the delivery partner is too big – they slow down decision-making and make it harder to respond to what users actually need.

“Big doesn’t mean best,” James says. “Big usually means status quo.”

Adoption is the real test

Ultimately, the success of a service is not defined by the scale of the programme that created it. It is defined by whether people choose to use it.

That is why listening to users once a service launches is so important. On one project, Sarah and the delivery team received thousands of pieces of feedback from people using the service. The Data and Insights team was prepared and quickly grouped the feedback, which was used to prioritise improvements.

“We could say we’ve heard you,” Sarah explains. “Here are the top things people are asking for, and here’s when they’re coming.”

This kind of transparency helps build confidence while services continue to develop.

Process or impact?

For James, there is also a broader question about how the UK approaches digital delivery in government. James believes departments sometimes prioritise process and safety over impact.

“We are now in a world where the speed of technology change requires leaders to act with more entrepreneurial spirit in service delivery, while acknowledging regulation and guardrails to ensure public trust is maintained,” he says. “We need to operate as leaders, not managers, to create a thriving future.”

That cautious mindset can slow progress at a time when expectations continue to rise. According to James, other countries have moved faster by treating digital services as ongoing products rather than fixed projects. It is, however, fair to acknowledge that some countries cited as examples don’t have the same issues around legacy debt that we have in the UK.

He does, however, believe that effective progress is still possible if organisations focus on outcomes and impact. “Start smaller, build the minimum viable product, release it and learn from it,” he suggests. “You might get some things wrong, but the overall cost will be lower and the service will improve faster.”

For Sarah, the practical advice is straightforward. “Be clear about the outcome you want to achieve. Define what a minimum viable product looks like. And be honest about what will come later. 

“Don’t be afraid to go with a minimum viable product. You learn so much once people actually start using it.”

Designing services around user needs does not mean ignoring the realities of government. It means working within them while keeping the focus firmly on what matters most.

James concludes by providing a trio of key takeaways that will drive technology change and enable leaders to put citizens and businesses at the heart of public services:

1. Policy is Digital and Digital is Policy: the two areas need to align further for future success
2. Adopt a product thinking approach to service delivery
3. Accelerate delivery and bring users closer via fast sprints and feature releases

“This is about leadership. Be clear on the outcome, give teams the space to deliver and stay close to what users actually need. If you do that, everything else starts to fall into place naturally.”

Learn more about our public safety and defence expertise and how Made Tech can help your organisation.

The post Putting citizens and businesses at the heart of public services appeared first on Made Tech.

Recently, I found myself in an unfamiliar position. I’d done thorough research, validated the findings, and used AI appropriately to synthesise a large volume of data. And yet, when I presented the work, it didn’t land in the way I expected.

The issue wasn’t the quality of the insights. It was the story I told with them, and how subtly that story had been shaped by the tools I used along the way.

This is a reflection on using AI in research storytelling: where it helped, where it quietly constrained my thinking, and what I’ll do differently next time.

The context: lots of data, sensible intentions

I’m currently working on a programme integrating a new off-the-shelf online data management system. As part of this work, I conducted research with two different internal stakeholder teams, as well as external users of the existing process/system.

The aim was to understand the “as-is” experience in full detail: the challenges, how they showed up across teams, and how they played out across the end-to-end journey.

The interviews returned a lot of data. Rich, nuanced, and detailed. The kind of dataset that’s incredibly valuable and slightly intimidating.

Where AI genuinely helped

This is where AI did exactly what it promised.

I used it to help:

• Synthesise large volumes of qualitative data
• Identify recurring themes and patterns
• Surface challenges across the end-to-end journey

It gave me speed, confidence, and reassurance that key insights weren’t being missed. I mapped the findings out across the “as-is” journey on a MIRO board and structured a report that presented challenges by each stage of the process.

At the outset, this felt entirely reasonable. Logical, even. If the team could clearly see where the pain was occurring, they could start to address it.

The problem I realised too late

As I moved into report writing – and later, presenting the findings – I could feel something wasn’t quite right.

The work was thorough.
The insights were accurate.
The facts were checked.

And yet, the findings felt repetitive. The narrative felt flat. Instead of a clear articulation of the big issues, the audience was being taken through a long list of challenges without a strong sense of what really mattered or how it all connected.

This was unusual for me. I’ve always considered storytelling a strength when presenting research. Normally, I move from synthesis on a MIRO or Mural board into a deck with relative ease, shaping insights into a narrative that helps teams think and act differently.

This time, that flow wasn’t there.

The subtle trap of AI-assisted structure

After the session, I spent time reflecting on what I’d done differently.

The key difference wasn’t the project or the complexity of the work; it was my starting point.

This time, I began with two detailed word reports that AI had helped me generate, outlining challenges by process stage. That’s not how I usually work. In the past, I’ve tended to move straight from visual synthesis into storytelling, shaping the narrative myself as I go.

Instead, I found myself reacting to a structure that already existed.

The structure made sense. It was coherent and comprehensive. But it wasn’t necessarily the story that needed to be told.

This is where AI can quietly lead you down a path you didn’t consciously choose:

• It produces a logical, complete structure
• That structure feels “right,” so it goes largely unquestioned
• You start optimising within it, rather than stepping back and reframing

Fact-checking didn’t solve this, because the problem wasn’t accuracy – it was meaning.

Why checking the facts isn’t enough

Everything in the report was correct.
That didn’t make it effective.

Good research storytelling isn’t just about describing what’s happening at each step of a journey. It’s about:

• What really matters
• What connects issues together
• What explains why things are breaking down
• What decision-makers actually need to understand

AI is excellent at surfacing what.
It’s far less capable of deciding so what.

That still requires human judgement, context, and a point of view.

Going back (and reframing the story)

I went back to the findings and reworked them into a shorter report with a very different structure. Instead of following the process end to end, it focused on a clear narrative about the core issues shaping the experience overall.

The result was:

• Shorter
• Clearer
• Easier to follow
• More actionable

In the process, I created two detailed Word reports, a needlessly long deck, and finally the report I should have produced at the outset.

That’s not time I’ll get back, but it is a lesson I’ll take forward.

What I’ve taken away

A few reflections I’ll be carrying with me:

1. AI is extremely helpful in making sense of complexity
   Especially when working with large volumes of qualitative data and needing confidence that key themes haven’t been missed.
2. The biggest risk isn’t over-reliance, it’s unexamined influence
   I didn’t outsource my thinking to AI, but I did allow an AI-generated structure to become the default frame for the story. That influence was subtle, logical, and easy to accept, which is exactly why it’s worth paying attention to.
3. Accuracy alone doesn’t create insight
   Everything in the report was correct. That didn’t make it coherent, compelling, or easy to act on.
4. Storytelling requires conscious human framing
   I was using my judgement throughout, but I wasn’t always aware of how my framing had been shaped upstream. The lesson wasn’t to “use my brain more,” but to pause earlier and ask whether this was truly the story I wanted to tell.

AI didn’t weaken this work, but it did make it easier to follow a path I wouldn’t have consciously chosen.

What I’ll do differently next time

• Use AI heavily for synthesis, but pause before locking in any AI-generated structure
• Sense-check the narrative before writing detailed reports or decks
• Ask: “If I had to explain this in three slides, what’s the story?”
• Separate process mapping from insight storytelling more deliberately
• Treat AI outputs as prompts, not starting points

AI can help you find the insights, but it’s still up to you to decide which story is worth telling.

The post When AI gets in the way of the story appeared first on Made Tech.

Why does this happen? Developing a data strategy is often treated as a one-off project or a purely technical exercise rather than a continuous, human-centred effort. Below, we explore some common pitfalls that can undermine a public sector data strategy and how to overcome them.

Common Pitfalls in Public Sector Data Strategy

Treating Strategy as a Document Instead of a Practice

It’s a mistake to focus on writing a “perfect” data strategy document and assume that alone will ensure success. In reality, a strategy that just sits on a shelf delivers no value unless people actually use it. A data strategy’s worth is measured by the actions and changes it drives, not by the weight of the document.

Overlooking People and Culture

Another common pitfall is fixating on technology while neglecting the human factor. Without the right skills, mindset, and data-friendly culture, even the best technology will fall flat. Successful data initiatives require investing in your people by building data literacy, encouraging collaboration, and getting buy-in at all levels. People are ultimately the ones who turn data strategy into real results.

Lack of Clear Purpose or Alignment

A strategy without a clear purpose or audience can become an academic exercise detached from reality. If it’s not clear who will benefit from your data initiatives or what value they will derive, the strategy will likely have little real impact. Ensure every data project is tied to a specific user need or organisational goal. A user-centred, mission-aligned strategy rallies support and delivers tangible outcomes because everyone can see the “why” and the “who” behind the effort.

Treating Data Strategy as One-Off, Not Ongoing

It’s tempting to consider your data strategy “done” once the document is published. In truth, a data strategy must be continually revisited and refined. The data landscape, public needs, and technologies are always evolving. If you treat your strategy as static, it will quickly become outdated. Instead, approach it as a dynamic, ongoing process (as Gartner puts it, a “highly dynamic process… in support of business objectives”). Regular reviews and updates will keep your strategy relevant and effective as conditions change.

From Pitfalls to Progress: How to Build a Successful Data Strategy

Avoiding the pitfalls above requires a holistic approach – one that combines people, process, and technology, and treats the strategy as a journey rather than a destination. Here are some steps public sector digital leaders can consider to turn a stalled data strategy into real-world progress:

Understand Your Starting Point (Data Maturity)

Before plotting where to go, you need to know where you are. A Data Maturity Assessment evaluates your organisation’s current data capabilities and highlights gaps in skills, processes, governance, or technology. At Made Tech, we often begin with this step – mapping out your data maturity provides a baseline and helps create a realistic roadmap for progress.

Align Strategy with Mission and Users

Audit your current data landscape and clarify your goals so that your data strategy directly supports your organisation’s mission and the needs of its users. Every project or initiative should tie back to a clear business objective or user outcome. At Made Tech, we collaborate through Data Strategy Support to help public sector teams define a clear vision and an actionable plan aligned to their purpose. This ensures the strategy is practical and focused on delivering value from day one.

Get the Right Technology and Architecture

Even a great plan can stall if your technical foundations can’t support it. It’s important to review whether your data infrastructure is fit for purpose – for example, ensure your data pipelines and storage solutions are modern and scalable, and that the right people have access to analytics tools. A thorough Technology and Architecture Review will highlight any gaps so you can address them early. By shoring up your tech stack, you ensure technology doesn’t become a bottleneck to your strategy’s success.

Invest in People and Skills

Technology alone can’t deliver a data-driven transformation – you need to empower the people behind it. Upskill your staff through training and mentoring so they have the confidence and capability to work with data effectively. Encourage a “one team” culture where technologists and domain experts collaborate closely. When people feel supported and see data making their jobs easier, they become champions of the strategy.

Establish Strong Data Governance and Ethics

Maintaining public trust is essential. Build governance into your strategy from the start – ensure privacy, security, and compliance (e.g. GDPR) are properly managed. Set clear policies, data quality standards, and access controls. Good governance not only prevents missteps but also builds confidence that data is handled responsibly. With the right framework in place, your organisation can innovate while staying within legal and ethical bounds.

Map Your Data Ecosystem

Public sector data environments are often complex and siloed. By visualising how data flows between teams and systems (using tools like the ODI’s mapping approach), you can uncover hidden bottlenecks and identify key data sources, stakeholders, and dependencies. This big-picture view highlights where processes could be streamlined or where risks (like bottlenecks or compliance gaps) exist. Ultimately, mapping your ecosystem leads to better oversight and more informed decisions.

Embrace Continuous Improvement and Innovation

A data strategy isn’t static – it should evolve with new learnings and changing technology. Once you have a solid foundation, you can explore advanced analytics or AI in a controlled, mission-aligned way. Keep treating your strategy as an ongoing journey: regularly review progress, measure outcomes, and be ready to adjust course as needs change. This commitment to continuous improvement ensures your strategy stays relevant and impactful.

Driving Data Success

Building a data-driven public sector organisation is no small task – but you don’t have to tackle it alone. At Made Tech, our 450+ experts have helped many public sector organisations navigate this journey, from assessing data maturity to implementing cutting-edge solutions. We work shoulder-to-shoulder with civil servants to build capability and deliver lasting outcomes.

Ultimately, a data strategy is not just a document – it’s a living program of change. By avoiding the common pitfalls and focusing on people, purpose, and continuous improvement, you can unlock the power of data to improve public services. If you’re ready to accelerate your organisation’s data journey or revive a stalled initiative, we invite you to explore Made Tech’s Data & AI services.

The post Unlocking the Power of Public Sector Data by Overcoming Common Strategy Pitfalls appeared first on Made Tech.

I’ve always been taught to use the Testing Pyramid¹.

The basic idea is to write the most unit tests, as they are the smallest in scope and fastest to run. Then you write fewer integration tests, which are larger in scope and slower to run, before you finally write an even smaller number of end-to-end tests, which are the largest in scope and slowest to run.

I’ve always been taught to use Test Driven Development²³ (TDD).

The basic idea of this is that you should write your tests before you write any code. Your tests codify the required behaviours of the software you then write, giving you an easy way to know when the feature you’re working on is complete. This should also document the context of the code you’ve written, making future changes theoretically easier.

But I keep observing common issues with unit testing on the digital delivery teams I’ve worked with over the past several years.

Recognise either of these from projects you’ve worked on?

Problem 1: Lack of test confidence – Your application fails when you deploy it, despite all the unit tests you’ve written for the change you’re making and high test coverage.

Problem 2: Testing stalls change – You make a simple change to your code, but you then need to totally restructure lots of unit tests in order to do it.

Problem 3: High cognitive load – You want to understand the behaviour of a section of your codebase, but reading the unit tests provides little help.

I’ve observed these problems dozens of times and they’ve always frustrated me because they seem to directly oppose the entire point of testing!

I believe good testing provides several significant benefits in software delivery:

1. Good tests should give us confidence in the correctness of our changes
2. Good tests should allow us to make changes more quickly
3. Good tests should document how our system behaves

Introducing the Testing Trophy

The culprit is the Testing Pyramid. It’s outdated and obsolete.

I’d like to introduce you to the Testing Trophy⁴⁵⁶ as a replacement. This is also sometimes known as the Testing Vase or Testing Honeycomb, but it’s essentially the same thing.

Integration tests are now the widest layer

The goal of these tests is to codify business logic. This typically means each test maps to either an individual acceptance criterion or an obvious, easy-to-understand part of a user journey.

For example, if your user journey is “to allow users to log in and check their health records”, you might have an integration test to check they can log in, another to check that a logged-in user can access their health records, and a third to check that a person’s health record displays the correct information.

Integration tests shouldn’t really care about the internals of your code. In theory, if you re-wrote your codebase in a new language, you should still be able to run the existing integration tests with minimal change needed.

Integration testing also avoids some of the common problems attributed to end-to-end testing – extremely long, brittle tests which fail intermittently. By splitting these long journeys up, integration tests are more reliable.

To address the three problems described above (lack of test confidence, testing stalls, and high cognitive load), I recommend migrating the bulk of your unit tests to integration tests.

End-to-end tests stay very thin

The goal of end-to-end testing is to ensure your application works as expected in an environment that closely replicates the production environment. In other words, they’re infrastructure tests. Only a few of these tests are needed, and they should cover complete user journeys.

To keep your end-to-end testbench manageable, it needs to rely on the presence of your integration testbench. This means you can keep the number of expensive end-to-end tests to a minimum.

Unit testing is now also a very thin layer

There are two goals for unit testing now: exhaustive testing and complex-subsystem testing. Both of these rely on your integration testbench to assert that your codebase actually works in a general sense, and only test very specific functionality that would otherwise slip through the cracks.

Exhaustive testing is for when you want to test all possible values or combinations within a feature. You could integration test the “common” combinations to check that the code works overall, but you could then add a unit test that would loop through every possible single value or combination of values to ensure they all still work.

For example, imagine you’re building an online shop, and you have integration tests that verify that users can successfully purchase green paint. Exhaustive unit tests could build on this to ensure the paint is also available in the 100s of other colours your shop offers.

Complex-subsystem testing is for when you have an isolated nugget of complexity in your codebase that you want to test in isolation. Because it has many edge cases and is complex, highly focused unit testing is important to ensure it works correctly. In essence, this pattern uses the same philosophy as integration testing our services as opaque boxes – just zoomed in to treat a specific class, module, or function as an opaque box instead.

For example, I once wrote a set of complex-subsystem unit tests for a smart rate limiter I was working on. You could integration test that the rate limiter works for several examples in the wider context of the application it lived within, but then add unit tests on top of this for every edge case you can think of for just the rate limiting logic.

Linting/Static analysis is the new base layer of the model

The goal of this layer is simply to speed up our ability to write quality code and tests. By using automated tools, we can catch more careless errors without having to test for them specifically.

And that’s the Testing Trophy!

What does this look like in practice though?

But what about the real world? It’s all well and good to evangelise a theoretical testing model, but how would you go about applying this to a real project you’re working on?

Below are some examples of common queries, and how I’d approach addressing them.

“I’m on a project with an OO codebase and lots of unit tests for each class. How can I introduce integration testing?”

• You can probably use your existing test runner (jest, junit, pytest, etc.) and extend it with tools like Localstack, Wiremock, or Test Containers.
• You can then write integration tests which read like chunks of a user journey or individual acceptance criteria. Something like “I want to allow users with an existing account to log in” or “I want to reject users who log in with the wrong password”. This is often referred to as Behavior Driven Development (BDD).
• You can convince your team with working code examples to back up what you’re saying. Hopefully, it shouldn’t take them long to see that writing a handful of integration tests with very few mocks saves them considerable time and effort!

“I’m working on a frontend using a modern JS framework. What does the testing trophy even look like for this codebase?”

• Render the entire app (and spin up any backend services) and use tools like Cypress or Playwright to end-to-end test full user journeys (e.g., logging in, adding a product to the basket, checking out, and requesting a refund).
• Render each page and click through multiple components to integration test. These tests should naturally make sense as parts of a user journey (i.e, a login flow).
• Render each significant visual component and verify that it renders correctly on screen during unit testing (exhaustive unit testing). You can also use tools such as Storybook or Chromatic to help with this.
• Render each complex (think lots of gnarly state logic, etc.) component and run through edge cases (complex subsystem unit testing).

“Our team has an end-to-end testbench which has all of our user stories in but is flakey, expensive to run, and breaks all the time. How do we fix this?”

• Is your entire end-to-end test stack running in a production-like environment? If not, fix this first! Even if it means you’re no longer able to run these tests locally, that’s an acceptable tradeoff.
• Are your tests actually written as full user journeys? Or do they try to do much more, testing edge cases or individual chunks of a user journey? If the test isn’t a full user journey through your system (e.g, I want to buy new shoes → my new shoes are on my feet), it probably belongs as an integration test.

“What’s the problem with just having lots of integration and lots of unit tests?”

• It’s fine to have partially overlapping tests! This is often a good pattern: an exhaustive unit test (the login button renders), an integration test (I can log in), and a larger e2e test (I can log in, buy something, and pay for it).
• If your integration tests are easy to run, can be run locally and debugged, having equivalent unit tests that try to do exactly the same thing is unnecessary, increases cognitive load, and runs the risk of rotting over time.

“My manager/boss says that we should aim for X% code coverage”

• Code coverage has diminishing returns (beyond 70%)⁷. It’s often good at revealing which chunks of a codebase haven’t been tested, but it’s bad at revealing which lines of code you should/shouldn’t be hitting.
• If their focus is on overall system performance, you could consider trialling DORA metrics⁸ within your team or organisation instead.
• They might start to trust you more when your new testbench starts automatically catching issues that the existing unit tests miss. I added a simple end-to-end testbench to a service our team owned, which had previously been very heavily unit-tested. It caught 5 bugs in the first month that would’ve otherwise gone to production without being spotted by the existing testbench.

“Our team has dedicated testers/SDETs, I don’t want to upset them by changing how we test”

• Most organisations employ testers to be test experts, not human computers. Most organisations and testers welcome automation and the increased confidence it brings through better testing.
• Bring them into the conversation early if you can. They’re likely to be highly in favour of new testbenches and better automation! After all, these tools make their jobs easier, freeing them up to focus on more important work like paying down test technical debt or activities like user acceptance testing (putting new stuff in front of actual users).

Annex – The types of tests

I want to take the time to define exactly what I mean when referring to all the different types of tests. In my experience, everyone has a subtly different definition of them – so for the sake of my sanity and your understanding, here are the definitions I’m using⁹¹⁰:

End-To-End (E2E) testing

Sometimes referred to as Functional, Integrated, System, or Smoke testing.

End-to-end tests are typically scoped to Level 1 (Software System) of the C4 model. Of all the tests, end-to-end tests are as realistic as you’re able to get and often need to be run in a production-like environment. These tests typically read like fully complete user-journeys.

External software systems are mocked as needed and pragmatic infrastructure changes are made (for example, running with fewer replicas than the production instance to save on server costs).

End-to-end tests are meant to be wide-reaching and realistic, at the expense of speed and ease of being run.

Integration testing

Sometimes referred to  as Functional, Component or Service testing.

Integration tests are typically scoped to Level 2 (Containers) of the C4 model. Integration tests are the middle child between end-to-end and unit tests, carefully balancing scope, speed, ease of running, and realism. These tests typically read like chunks of a user-journey, or specific acceptance criteria.

Other major components of your software system are mocked out, and tightly-coupled parts aren’t. For example, integration tests for a login API might mock everything except the API, a database storing login credentials, and a queue which login requests are read from. Infrastructure is also often mocked, with tools such as docker, localstack, or lightweight kubernetes clusters being popular choices to only stand up a small handful of tightly-coupled services.

Integration tests are a balance between being closer to reality, treating your software as an opaque box unlike unit testing; and fast and simple to write/run, unlike slower and more brittle end-to-end tests.

Unit testing

Unit tests don’t really go by any other names, but there are a million competing definitions of what constitutes a “unit” of software!

Unit tests are typically scoped to either Level 3 (Components) or Level 4 (Code) of the C4 model. Due to the limited scope of these tests, other classes/modules/functions/objects within the same codebase are mocked as needed.

Unit tests are meant to be quick to write and run, at the expense of scope and realism.

Static analysis

Sometimes also known as linting. Static analysis covers a vast array of tools and automations and can often be found in places like pre-commit hooks, continuous integration pipelines, and even your code editor. This bundles together linters, formatters, type checkers,

Static analysis tools are typically scoped to Level 4 (Code) of the C4 model. They aren’t really “tests” in the traditional sense, but enforce things like code styling and good practices.

Ideally, they should be run as close to code being written as possible for the shortest feedback loop possible.

1. Mark Cohn – Succeeding with Agile: Software Development Using Scrum, 2009 ↩︎
2. https://martinfowler.com/bliki/TestDrivenDevelopment.html ↩︎
3. https://www.madetech.com/blog/messy-software-projects/ ↩︎
4. https://www.wiremock.io/post/rethinking-the-testing-pyramid ↩︎
5. https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications ↩︎
6. https://kentcdodds.com/blog/write-tests ↩︎
7. https://kentcdodds.com/blog/write-tests#not-too-many ↩︎
8. https://www.thoughtworks.com/en-gb/insights/articles/improving-your-bottom-line-with-four-key-metrics ↩︎
9. https://martinfowler.com/bliki/UnitTest.html#SolitaryOrSociable ↩︎
10. https://martinfowler.com/articles/practical-test-pyramid.html ↩︎

The post A pyramid scheme! Have we been unit testing wrong? appeared first on Made Tech.

We launched our apprenticeship programme as part of our long-standing commitment to grow digital capability and deliver social value through our work. Since founding Made Tech, we’ve invested heavily in early career pathways, including our engineering academy. Apprenticeships were a natural next step, combining learning with real-world delivery experience. 

The goals of our apprenticeship programme are simple but ambitious:

• Develop future-ready digital talent
  
• Create accessible entry routes into tech careers
  
• Build long-term capability for public sector delivery
  
• Raise standards in practical, work-based technical training
  
• Support business and client outcomes through a strong talent pipeline

Innovation is at the heart of the technology sector, and our apprenticeship programmes are no different. Our Learning & Development team has worked hard to integrate several innovative approaches into our programme delivery to ensure that our apprentices expand their consultancy skills alongside their technical training. 

A blended model built around delivery

We use a blended learning model that combines traditional classroom-based learning with hands-on, client-facing work. Apprentices balance their time between structured learning sessions and practical project delivery, allowing them to apply their learning in real-life scenarios. This approach helps consolidate their understanding and keeps learning grounded in the realities of modern digital delivery. Instead of learning theory first and practice later, apprentices build confidence by doing both simultaneously.

Developing consultants, not just engineers

Great public sector digital delivery relies on more than technical skills alone. It requires collaboration, communication, and sound judgment too. That’s why our apprentices work on cross-functional teams, which allows them to interact with other specialisms and gain a deeper understanding of how Made Tech operates. This helps them develop strong communication, collaboration and problem-solving skills – consulting skills that matter just as much as technical capability. 

Learning through gamification

To further enhance apprentice engagement, we have incorporated gamification elements into our curriculum to make learning more interactive. These practical exercises give apprentices a chance to test their thinking, strengthen their technical skills and tackle problems in a more dynamic format.

Competitions and events

We encourage apprentices to test their skills beyond their day-to-day work whenever possible. Recent cohorts have participated in external competitions such as the NASA Space Challenge, which provided them with the opportunity to showcase their talents and challenge their abilities, whilst also engaging with individuals outside of Made Tech. We believe that these competitions and external events will foster healthy competition and drive excellence, enabling apprentices to benchmark their skills against peers across the industry whilst gaining confidence and experience under pressure. 

Assessments that mirror real work

Our assessments are not abstract tasks. They are designed around real-life challenges that we encounter at Made Tech and the work we do for our clients. To make the experience as authentic as possible, we involve relevant stakeholders and, at times, clients throughout the project milestones so the work feels authentic and outcome-focused. By doing this, we aim to give apprentices a clear understanding of the impact of their work and how their contributions can make a meaningful difference for our clients and the broader community. 

Continuous feedback

Feedback shouldn’t be something that only happens at the end of a module. At Made Tech, we implement a continuous feedback system built into the rhythm of the programme. Through regular check-ins, learning reviews, and weekly journals, apprentices receive ongoing feedback, enabling them to adjust quickly, build self-awareness and keep progressing steadily. This approach ensures learning remains ongoing and helps our apprentices stay on track, with support provided where required. 

Career guidance from day one 

Starting a career in tech can feel exciting – and overwhelming. We support our apprentices with structured career information, advice, and guidance throughout their apprenticeship. Our CIAG (Careers Information, Advice and Guidance) programme is a dedicated initiative that supports our apprentices as they build a confident, informed pathway to their future careers. The transition into the workforce is both exciting and daunting, and our programme is designed to provide clear, consistent, and high-quality guidance every step of the way.

Looking ahead

National Apprenticeship Week is a celebration, but it’s also a reminder that workforce development is long-term work. Strong programmes are built through iteration, feedback and partnership.

We’re proud of what our apprentices have already achieved, not just in qualifications gained, but in services improved and teams strengthened. As we grow the programme, our focus remains the same: high-quality learning, real delivery impact and genuine career progression.

If you’re interested in starting a career in digital and technology, we’d love to hear from you.

The post How our innovative apprenticeship programme is building the next generation of public sector technologists appeared first on Made Tech.

I came into tech as a career changer. After seven years working in the NHS as a Physiotherapist, I took a leap into coding through a bootcamp, which led me to a role as an Apprentice Software Engineer at Made Tech. 

The Made Tech apprenticeship programme

From the very start, it was clear that this apprenticeship was about far more than just learning to code. While technical skills are essential, the programme takes a holistic approach to development. Early on, we explored topics such as Equality, Diversity & Inclusion, British Values, Power, Privilege & Responsibility, and Non-Violent Communication, among many others. Learning about these subjects showed me that this apprenticeship isn’t just about becoming a better engineer, but it’s about becoming a more well-rounded, capable professional. 

You might think that, after years in healthcare, I would have already honed my communication and teamwork skills, and, to some extent, I thought I had too. Yet, this apprenticeship has shown me that learning never stops, and there are always new ways to grow both professionally and personally. 

Turning learning into practical experience

A highlight for me has been joining a delivery team where I get hands-on experience every day, not just with coding, but with collaboration, communication, and teamwork. Pairing with senior engineers allows me to learn in real time, gaining practical insights and guidance that you simply can’t get from textbooks alone. It also inspires me to see the career path I hope to follow one day. 

Having completed a university degree in the past, I can honestly say that this apprenticeship offers a different and incredibly valuable way of learning. Being immersed in ‘on-the-job’ experience has given me confidence, practical skills, and a sense of contribution from day one. While it can feel like being thrown into the deep end initially, that challenge quickly becomes an opportunity for rapid growth. Moments of discomfort or imposter syndrome are normal, but learning to navigate them is part of the process, and it’s what enables true development. 

The value of apprenticeships

Apprenticeships don’t just fill skills gaps for businesses; they transform lives, opening doors to careers and personal growth that might once have felt out of reach. My journey is proof of that, and I am proud to celebrate National Apprenticeship Week by sharing it.

Since 2023, our apprenticeship programme has been part of our long-standing commitment to broaden access to digital and tech careers while strengthening the skills base that public sector delivery depends on. To find out more about building a career in tech through the Made Tech apprenticeship programme.

The post Celebrating Growth and Opportunity: My Apprenticeship Journey appeared first on Made Tech.

As the first event organised by the recently formed GDS Local unit within the Department for Science, Innovation and Technology, it also provided a perfect platform to showcase GDS Local’s ambitions to work with councils to improve local services. 

Over two intensive days, 150 participants from 70 organisations came together in 14 multidisciplinary teams to create solutions to some of the most pressing challenges facing local government today: homelessness, rough sleeping, and temporary accommodation. The teams then had less than  24 hours to build working prototypes in response to real-world challenge statements set by the organisers.

Our colleagues Jo Frances, Matthew McElroy, and Geettika Kejriwal had the opportunity to take part, and their reflections offer a vivid picture of how this hackathon set a new benchmark for innovation and what the wider public sector can learn from it.

A hackathon designed around real public sector problems

From the outset, MHCLG shaped this hackathon to ensure impact rather than abstraction. Instead of generic prompts, participants chose from three strategic, human-centred challenge statements that could be addressed using data and AI solutions. Each of these was rooted in lived experience, operational realities and policy priorities:

• Using Data and AI to predict and prevent homelessness: How might we ethically harness data and AI to identify individuals or households at risk of homelessness, and enable effective, trusted early interventions?
  
• AI driven outreach and system efficiency for homelessness and rough sleeping services: How might we ethically leverage AI and digital tools to streamline case management, enhance outreach, and improve the usability of homelessness support systems?
  
• Optimising temporary accommodation allocation through data driven insights: How might we leverage data and analytics to optimise the allocation and management of temporary accommodation ensuring resources are used efficiently, individual needs are met, and families spend the shortest possible time in temporary accommodation?
  

Speakers from MHCLG, Birmingham City Council and frontline services emphasised the urgency of rising homelessness presentations, the strain on temporary accommodation, and the need to shift from crisis response to prevention. Birmingham alone recorded 300 homelessness presentations per week, and over 5,200 households in temporary accommodation, including 11,279 children.

By grounding each challenge in real data, system pressures, and lived experiences, teams felt they weren’t just building prototypes; they were creating solutions for real people.

The Power of Multidisciplinary Teams

Jo, Matthew, and Geettika all stressed that the real value of the hackathon wasn’t the outputs but the people in the room.

Their teams included:

• Technical specialists
  
• Local authority caseworkers with deep domain expertise
  
• People with lived experience of homelessness
  
• User researchers and designers
  
• Policy experts
  
• Social value practitioners
  

This diversity created what Jo described as the power of bringing the right people together.

The technical skill in that room was exceptional — I was genuinely in awe of the solutions people built in two half days of dev time. But what made it powerful wasn’t just the tech. It was having people with lived experience, council caseworkers, designers, data experts, policy leads and technologists all working side by side. You could feel how much everyone cared about getting this right.

Caseworkers sketched real user journeys on the fly. Designers tested assumptions. Technical specialists translated insights into prototypes. Mentors and facilitators from GDS Local and MHCLG moved between teams, adding context and challenging thinking. The environment was fast-paced, collaborative and energising.

Matthew highlighted that being embedded in mixed teams gave him direct exposure to how homelessness services operate, the pain points, and where technology could make a meaningful difference.

I was on a team with four or five people from local authorities who work in homelessness day in, day out. Seeing them draw the user journey — where the pain points are, where people fall through the cracks — was invaluable. It made every design and data decision feel grounded. We weren’t guessing; we were learning directly from the people who know the system best.

This mix of expertise, experience, and execution transformed the event from a hackathon into a genuine innovation engine.

Building high-quality prototypes at speed

Over just two half-days, teams delivered working demos that:

• Merged datasets for early risk identification
  
• Used AI to streamline case management
  
• Suggested smarter, more human placement decisions for temporary accommodation
  
• Improved resident engagement
  
• Facilitated cross-authority insights into rough sleeping
  

Jo noted that the technical quality was exceptional, with some prototypes looking like early-stage products rather than 36-hour builds.

To help them deliver their prototypes, teams were given access to a variety of datasets, including statutory homelessness data and rough sleeping counts, deprivation indices, social housing data, and predictive indicators.

They were encouraged to use these responsibly, in line with MHCLG’s guidance on ethical, human-centred AI.

The result? Solutions that balanced ambition with practicality by utilising all the expertise in the room. Built around the people we are trying to help, and the organisations and people who support them. 

Beyond the outputs themselves, the hackathon also served as an accelerated learning environment for everyone involved. Participants had the opportunity to experiment with AI tools, explore emerging capabilities, and quickly benchmark their peers’ day-to-day use of AI.

Geettika highlighted that it felt less like a traditional event and more like an accelerated masterclass in AI tools.

Recognising the importance of social value

Geettika’s team received a special mention for its focus on social capital, a dimension often overlooked in technical innovation. Their solution highlighted the importance of community, support networks and relational factors in homelessness journeys.

The caseworkers in our team brought the richness of years of experience that informed our solution. Understanding the social context of person A and person B, who may appear similar at first glance, but a peek into their social connections reveals something that can add value to what big data is telling us. This might just be the innovative perspective we need to solve some of the complex problems in society.

This emphasis aligns with sector-wide reflections: homelessness is not just a housing issue; it’s a social, economic and human one. Solutions that strengthen relationships and resilience can be as impactful as those that optimise systems or automate processes.

A model other government departments can learn from

Everyone agreed: this event set a benchmark.

It demonstrated the value of:

• Cross-government collaboration
  
• Shared datasets and transparent challenge statements
  
• A “test and learn” culture
  
• Embedding service users in the design process
  
• Freeing teams from business-as-usual constraints
  

Jo put it best: the hackathon showed what’s possible when you bring experts and builders into the same room with a clear mission.

This is absolutely something other departments could replicate. If you can bring together experts who have kindly volunteered their time – technical, domain, and lived experience – and focus it on a real challenge for two days, the value is enormous. MHCLG created a space where people built things that could meaningfully improve lives.

Matthew added that it elevated conversations about homelessness and digital innovation into spaces where ministers and senior leaders engage, increasing the likelihood that promising ideas will be supported, scaled or funded.

One of the best ways to get ideas in front of senior leaders and ministers, because hackathons strip away hierarchy. You’re suddenly in a room where everyone’s equal — from developers to directors — and you’re all focused on solving the same problem.

Homelessness is complex. No single tool, dataset or organisation can solve it alone.

This hackathon highlighted three truths:

1. Innovation thrives when people with different expertise work side-by-side.

Local government holds the insight. Technologists hold the capability. Lived experience gives direction. Together, they produce meaningful solutions.

2. Data becomes powerful when shared, contextualised and tied to real outcomes.

The local government presentations from London, Barnsley, and Somerset illustrated the range of activities already underway across local government, showing how data and AI are being used by local authorities to better understand demand, support frontline decision-making, and inform service improvement.

3. Collaboration accelerates change.

In two days, teams built prototypes that could otherwise take months. The concentrated energy and interdisciplinary teams unlocked creativity in a way standard delivery cycles rarely allow.

Final reflections: Innovation is a team sport

For Jo, Matthew, and everyone who attended, the biggest takeaway wasn’t just the solutions but the hackathon setup itself.

A model where:

• Hierarchies flatten
  
• Expertise is shared
  
• Creativity is valued
  
• Public service challenges are treated with urgency and humanity
  
• And people come together because they believe in making things better
  

The public sector is full of committed, talented people. When they’re given the space, support and permission to collaborate — as they were in Birmingham — genuine innovation becomes not just possible, but inevitable.

Geettika share a similar sentiment, noting that:

My biggest takeaway from the day was understanding where my industry peers are at and how we as design consultants are using tools to aid our work. Learning tools and building the confidence to use them in 2 days felt almost like an expedited masterclass. The hackathon left me feeling inspired and refreshed.

Find out more about our Data and AI expertise.

The post The power of bringing people together: Key takeaways from the Local Government Innovation Hackathon appeared first on Made Tech.