Modernising legacy technology has never been about simply replacing what exists. As we saw in the previous article, the real challenge is understanding complex systems and improving them without disrupting the services that depend on them.

AI is now accelerating that process. It is changing how teams analyse, rebuild and improve legacy systems, but it is not removing the need for careful engineering or clear thinking.

Ben Pirt, Principal Technologist at Made Tech, describes the impact of AI. “It has been phenomenally helpful in understanding a legacy codebase,” he says. “With the right inputs, AI can analyse structures, surface relationships and explain how systems behave in a way that would previously have taken weeks or months to piece together.”

That kind of visibility matters because discovery is often the slowest part of modernisation. Teams need to understand not just what a system does, but why it behaves the way it does, and how that connects to real-world processes. AI does not remove the need for that work, but it can accelerate it significantly.

Speeding up redevelopment without losing control

It is also starting to change how redevelopment happens. In one example, teams used AI to extract behaviours from a legacy codebase and treat those behaviours as a set of specifications. They then used AI to reimplement those behaviours in a new language, bringing tests across at the same time.

The results were immediate. “A week-long test got through a huge amount,” Ben says. “For certain types of work, particularly where patterns are well understood, AI can speed up delivery in a way that would have been difficult to achieve even a year ago.”

That is especially true for more repetitive tasks. Building API endpoints, following established patterns and generating boilerplate code are all areas where AI is already performing well. As Ben puts it, it is “insanely good” at following structured instructions.

It would be easy to see this as a shortcut to solving legacy problems, but the reality is more complex. AI can move things forward quickly, but it can also replicate existing issues just as fast if it is not used carefully.

“If you just say to AI, ‘port this code’, it’ll do it,” Ben explains. “But it might not do it very well.” In that scenario, the risk is that you carry forward the same poor design into a new environment, rather than improving it.

That is why engineering discipline still matters. If anything, it matters more. Strong testing, clear specifications and careful validation are what make AI useful rather than risky.

Just as importantly, organisations need permission to approach AI incrementally. That often means starting in low-risk areas, testing where it adds value, and creating space for teams to learn without feeling they have to bet the service on a single decision. In practice, responsible innovation often depends as much on creating that permission as it does on the technology itself.

Ben describes using AI within a controlled, test-driven approach. Behaviour is extracted, verified against the existing system and then used to guide the new implementation. The AI is not left to decide what “good” looks like on its own; it is constrained by clear rules and expectations.

“If you force it down a rigorous path, you can get extremely good quality,” he says. “Without that structure, the outputs are far less reliable.”

That structure also has to include transparency and governance. If AI is helping analyse, generate or recommend changes to legacy systems, teams need to understand how those outputs are reached, how decisions are validated, and where accountability sits.

Avoiding a new generation of technical debt

There is also a broader question about how AI is used across organisations. As tools become more accessible, it becomes easier for teams to build solutions quickly. That can be a positive shift, but it also introduces a familiar risk. Geraldine Mathews, Client Partner at Made Tech, highlights the concern that organisations may start solving problems in isolation. One team builds something for one part of the service, another team builds something elsewhere, and the overall journey becomes more fragmented rather than less.

“It’s got to be about the full user journey,” she says. “Without that focus, there is a real chance of creating a new layer of technical debt on top of the old one.”

Geraldine continues: “This is where the conversation becomes particularly interesting. AI is often positioned as a way to reduce technical debt, but it may also change what technical debt looks like. Instead of slow, ageing systems, the risk becomes fast-moving, disconnected ones.

“The technology itself is not the issue. The challenge is how it is applied. Without a clear delivery approach, strong architecture and a shared understanding of user needs, speed can work against you.”

AI is an accelerator, not a shortcut

At the same time, expectations are rising quickly. Organisations are seeing demonstrations of AI rewriting legacy systems and naturally begin to expect similar results. As Geraldine notes, “the expectation is going to be very high now”.

“That creates pressure to move faster, but it also increases the importance of getting things right. Delivering quickly is only useful if what you deliver is coherent, maintainable and aligned with how people actually work.”

This is also where risk assessment becomes practical. Rather than asking whether AI should or should not be used, the better question is where it is appropriate, where human oversight should remain, and how risks can be reduced through staged delivery. That is often where Made Tech works closely with clients, assessing the service, identifying suitable use cases, and proving approaches safely before scaling them into live environments.

Geraldine continues: “There is also a question about how far AI can go in redefining legacy modernisation. Some suggest that older systems can simply be translated into modern stacks with minimal effort. While that is technically possible, it risks missing a key opportunity.

“Porting a system does not improve it. It changes the environment it runs in, but it does not address the underlying design issues or the mismatch with user needs. Without that deeper work, the same problems are likely to resurface.”

That is why the fundamentals remain the same. Understanding users, designing around real workflows and building systems that can evolve over time are still central to successful modernisation. AI can support that process, but it cannot replace it.

In practice, the most effective use of AI is as an accelerator rather than a solution in its own right. It helps teams understand systems more quickly, test ideas more thoroughly and deliver certain types of work more efficiently.

What it does not do is remove the need for judgement. As Ben puts it, the best engineering practices still apply, and in many cases, they become even more important when AI is involved.

Looking ahead, the role of AI in legacy modernisation is likely to evolve quickly. The organisations that benefit most will not be the ones that adopt it fastest, but the ones that use it most thoughtfully.

In that sense, AI does not change the goal of modernisation. It changes how effectively that goal can be achieved, provided the focus remains on building systems that genuinely work for the people who rely on them.

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

The post AI is an accelerator, not a shortcut, when tackling legacy systems 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.

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.

Masood Khalid

Masood’s pivot to data engineering began during his Actuarial Science degree, where he discovered a keen interest in data analysis. He realised his passion for data and joined a graduate scheme that trained him as a data engineer, ultimately leading him to his current role at Made Tech.

What would you say to anyone looking to work in tech?

From my experience, certifications don’t cut it. You need to have experience. Find ways to implement your interests into your own personal projects. I have upskilled a lot and frankly if there was a leaderboard for how many certifications you could do within a short amount of time I’d be up there.

At the end of the day there’s no replacement for real experience and the only way to avoid the slow grindy feeling of doing those projects is to bring in your own interests. The more you do that, the more motivated you’ll be, the more inspired you‘ll be and the easier it will be for you to keep getting that experience whilst not having a job within the industry.

If you’re looking to get in, that’s my best advice. It is a bit daunting. You just have to keep chipping away at it until you get to the point where you can tie all these different fields together and you can build products and new projects on the whim whenever it takes your fancy.

What do you enjoy most about your role?

I love the variety. Thanks to the varied nature of the work here, I’ve been able to get some of my own interests involved in some of the tools I use day-to-day. I’ve got a good amount of personal projects going on. It really helps that you learn a lot of this stuff while you’re doing the work. There’s a lot of support for that here at Made Tech. We have a learning budget to use which really helps too. 

There’s a lot of different people you work with. We’re hugely cross-functional. I work with software engineers quite a bit and so we have meetings to make sure we’re not clashing or butting heads over shared infrastructure. A lot of their work flows downstream into what we do, and so a lot of our work is built upon what they’ve built in the frontend application. There’s lots to do and there’s a lot of people from different fields to work with.

Do you have any advice for anyone looking to join the team?

Out of all the places I’ve interviewed for, Made Tech does a really good job of keeping the job descriptions up to date and relevant. Read that job description because it is updated frequently. 

If you’re more junior, you stand a better chance if you can show how passionate you are. There’s a lot of projects and learning you can do to bolster your portfolio and CV if you don’t have experience yet.

Sophie Wenban

Sophie moved from video production to data engineering. She self-studied Python and completed the AWS re/Start programme. Starting at Made Tech as an associate software engineer, a databases module and a love for pipeline work inspired her shift to data engineering.

What’s a typical day in your life as a Made Tech data engineer?

My day typically kicks off with a coffee as I catch up on Slack messages and emails. My first priority is always checking our dedicated Slack channel for pipeline failure alerts, ensuring our overnight data ingestion and transformation jobs ran smoothly. I then review my to-do list, which helps me quickly re-engage with my tasks and ensures a smooth start to the day.

At 10am my team gathers for our daily stand-up. I provide a quick update on my progress and flag any blockers. If I’m stuck on a ticket, we’ll quickly agree on who can help, often jumping straight onto a call after stand-up to work through the problem together.

If there are no immediate issues, I dive back into my current ticket or pick up the next high-priority item. Collaboration is a big part of our day. We often jump on calls to discuss tickets and sometimes we’ll use pair programming to tackle challenges together.

In the afternoon I’ll jump back into my ticket or carry out a peer review if another engineer has completed a piece of work.

Towards the end of the day, I consolidate my notes and prepare my to-do list for tomorrow. This ensures I can hit the ground running, picking up exactly where I left off, ready for the next day’s challenges.

Can you tell us a little bit about the data community?

The data and AI community at Made Tech is truly a fantastic group of people. I’ve found everyone to be incredibly welcoming since joining.

We foster our community through regular events. Every week, we hold a Community of Practice (CoP) session. These are great opportunities for individuals or groups to share their work, discuss interesting technologies they’ve explored or talk about their experiences working in data. It’s a brilliant way for us to learn from each other and stay connected.

Beyond our CoP sessions, we also have a monthly remote lunch. These are more informal gatherings with no set agenda, which is perfect for getting to know colleagues better, especially since many of us work on different teams. It’s a really nice way to build connections and reinforce the welcoming atmosphere of our community.

What do you enjoy most about your role?

The direct impact my work has. I love helping organisations leverage the valuable data they hold. We partner with government departments and arm’s-length bodies and the insights we help them glean from their data can lead to real, positive change for the public. 

It’s incredibly rewarding to know that the technical work I do contributes to better public services and informed decisions that can benefit many.

Do you have any tips for anyone interviewing at Made Tech?

Pay close attention to the interview calendar invites you’re sent. They include really helpful information about what format the interviews will take, the type of activities you’ll be asked to do and some of the questions and topics you’ll be asked about.

Use these to help yourself prepare, think of experiences you can share when answering these questions and be prepared for follow-up questions.

Lee Broadhurst

Lee moved into tech after 8 years at Lloyds Banking Group. He self-taught coding for a year and completed the Northcoders bootcamp in 2022. In early 2023, he joined the Made Tech Academy as an associate software engineer, gaining 2 years of experience. A project building a client’s data platform gave him hands-on data engineering experience, leading to his transition into a data engineer role after 6 months.

If someone were to shadow you for a day, what kind of tasks would they see?

I start at 9:00am and usually spend the first 30 mins making sure that I’m up to speed with any Made Tech announcements and admins tasks. I also use this time to reflect on my previous day’s work and plans for the day ahead.

At 9:30am my project team has a daily stand up where we each provide an update on our assigned tasks. From 10:00am my day can vary quite a lot but it will often involve working on my assigned tickets, attending meetings and planning sessions or preparing to present the progress of my work to the client in Show and Tells.

Currently, I’m working on building data pipelines in a data lakehouse architecture using Databricks and Azure. I’ll often be collaborating with other data engineers and analysts to understand and implement the requirements of the client. 

Are there any areas you’re focusing on in your development right now?

I’m lucky to be working on a project where the work itself aligns with my development goals. So I get to learn whilst also being an impactful member of the team. In the last couple of months I’ve gained a lot of experience working with Databricks, Terraform and Azure so I’ll be using my learning days and annual learning budget to work through courses relating to these.

What’s your #1 tip for people who want to work in tech?

Find a learning resource that interests you and complements your learning style. Learn the foundational skills required for the role you’re working towards and try not to get distracted by all the different technologies. 

Whilst technical ability is important, it’s not the most important skill to have to work in tech. Especially at a consultancy like Made Tech. The softer skills are equally important. You may already have a lot of what’s required, especially if you’re coming from another career that requires a similar skill set.

What type of workplace culture is most important to you?

A lot of my job satisfaction comes from feeling valued by the data community and the teams I work in. Everyone is encouraging and this has helped a lot with my career progression and confidence in my ability. 

How do data engineers at Made Tech typically collaborate and share knowledge?

The data community at Made Tech is great. Everyone is friendly, supportive and keen to help each other grow. We have a Data Community of Practice call every couple of weeks. A member of the community will present something they’ve been learning or working on, or we’ll have a guest speaker attend the session.

Recently, we all got together at a venue in London for a strategy and alignment day, focusing on the future vision of Data and AI Made Tech. We had talks from members of the data community and plenty of opportunities to get to know each other more.

If hearing from our data engineers has piqued your interest in working with us, great news – we’re hiring! 

The post Meet the Data Engineers of Made Tech appeared first on Made Tech.

The way around this may be to think smaller. Small Language Models (SLMs) are emerging as a much more sustainable and scalable way to adopt AI. They may not be as ‘powerful’ as Large Language Models (LLMs) but they offer unique benefits that allow projects to escape the testing phase and solve real world problems. 

Bigger isn’t always better when it comes to AI

A lot of clients come to us with the assumption that more power equals better results. The thinking is: if we use the biggest, most powerful model out there, we’ll be covered. But in practice, those LLMs  bring complications along with their power and size , especially for well-defined, specific use cases.

Think of it like driving through London. If you try to do it in a van or lorry – yes, it’s big and powerful – but is it the right choice for narrow urban streets? Not really. In that environment, a small city car that’s lighter, less powerful and more affordable is actually the better idea.

SLMs are designed to do one thing well. They’re faster to train, are cheaper to deploy and easier to iterate. You can get 80% of the results with 20% of the resources. And that’s often more than enough, particularly when you’re building a proof of concept or delivering something operational in a short timeframe.

A real-world example: Making sense of millions of data points

We saw this approach pay off recently on a project where a team was facing a familiar challenge. They had over 1.3 million free-text user comments that needed to be categorised and analysed. That entire workload was falling on a single analyst. They weren’t looking for an advanced AI assistant. They just needed a faster, smarter way to surface the right insights from an ever-growing dataset.

So we built a solution using TinyLLaMA, a small model just 638MB in size (just under one hour of standard-definition Netflix streaming). It didn’t need to understand everything. It just needed to take a user prompt like:

“Show me comments about the event between 01/04/2025 and 05/04/2025”

…and turn it into a structured query.

That output would then search a vector database, and within seconds, return a bespoke dataset related to the topic of the query. No overkill. No unnecessary complexity. Just a tool that did one thing well and did it fast.

And the great thing? We didn’t need a lot of infrastructure or resources to make it happen. We deployed it via AWS, but can run it locally too if needed.

Why Small Language Models work

What made that project successful wasn’t just the tech. It was how specific we were with the problem and the data. We didn’t train the model on everything, we trained it on exactly what it needed to perform the task.

Too often in AI, we see teams default to ‘the more data the better’. But actually, data quality and relevance beat data volume every time. In this case, we used real prompts from users to train the model. That specificity meant out of the box we could train, refine and implement much quicker than with a LLM and get our model trained on our specific use case more quickly.

Ease of use = Better adoption

The other big win here was ease of use, giving a powerful tool to users without them needing to know anything about vector searches or language models. They just asked a question in plain English to a Graphical User Interface (GUI) and they got a bespoke data set. That’s the kind of user experience that drives adoption. We’re not asking them to learn how the engine works. We’re handing them the keys and letting them drive.

Building AI responsibly with small language models

Another reason I’m a big advocate for SLMs is that they’re easier to govern, can be implemented with ethics at their core and have less of an environmental impact on the planet.

Because the model is small, you can see exactly what’s going in and coming out. That means it’s easier to:

• Discover bias behaviour: With tighter control of the data going into the model we can be proactive in auditing and tracking data.
• Understand the output: SLMs are less of a black box than LLMs, thanks to their focused training and lower complexity. This makes their output easier to explain and builds greater confidence among stakeholders.
• Comply with GDPR: With the use of domain specific data sets, it’s much easier to meet GDPR standards and remove specific data from training the model. 
• Be greener and more sustainable: SLMs are smaller across the board, this means; less computational resources, significantly lower energy consumption and reduced carbon emission. We can help clients cut costs and achieve their emission objectives. 

Think fit for purpose

The calculator didn’t replace the accountant, it became a tool in their arsenal. When AI is built around a specific problem and designed with users in mind, it becomes a tool people want to use, not one they fear.

That’s the power of small models. They let you move fast, stay focused and build something that solves users’ real world problems.

If you’re thinking about scaling AI in your organisation, I’d encourage you to ask:

• Do you know what problem you’re actually trying to solve?
  
• Do you have the right data – not just lots of it?
  
• Do you need a general-purpose model, or one that’s tailored to your needs?

If you’ve got a clear use case, you don’t need to go big. Small, focused AI can get you there faster and with less risk.

Take a look at our data and AI pages for more on what we have to offer.

The post Scaling AI responsibly with Small Language Models (SLMs) appeared first on Made Tech.

In our work with public sector clients, we’ve found that identifying the right use cases isn’t just helpful. It’s absolutely critical. The organisations that succeed with AI are the ones that begin by asking: what problem are we solving, and is AI the answer?

Why use cases matter as much as tech specs

AI adoption often fails when it’s driven by hype, not need. Departments rush to implement complex models without a solid understanding of what they’re trying to achieve. This results in stalled projects and wasted investment.

Our whitepaper Laying the groundwork for AI outlines common archetypes we see in public sector organisations. One of the most damaging? The ‘over-ambitious use case’, where aspirations outpace the organisation’s data and infrastructure readiness. These projects rarely succeed, because they lack a firm foundation built on actual needs, leading to not only high development costs but also inflated operational costs.

By contrast, when organisations start with the right use cases aligned to their goals and scaled to their capabilities, they lay the groundwork for sustainable AI adoption.

Use cases drive AI readiness

Choosing the right use case doesn’t just help you prove AI’s value. It drives maturity in the other areas that matter for long-term success: technology and culture.

In one example from a local government client, we were brought in to rebuild their data platform following a cyber attack. While the initial focus was on restoring technology, the new platform introduced capabilities the organisation hadn’t previously had. This created the need for new skills and training causing a shift in culture. And, as those skills grew, teams started to spot and implement new AI-ready use cases that were previously out of reach. One investment triggered change across all three pillars of data maturity: tech, culture and use case.

That’s how AI success happens. Not in isolation, but by letting use cases guide the journey.

The helical model: how to unlock momentum

The helical model described in our whitepaper reflects the real-world interplay between technology, use case and culture. Rather than treating them as silos, we see how investment in one area creates the right kind of tension to drive growth in the others.

A great example of this came from our work with the Department for Business and Trade (DBT). The project started not with technology, but with a clear use case. Their teams were struggling with an in-house CRM system that didn’t meet their operational needs. Data was fragmented, reporting was inconsistent and the system was difficult to maintain. The CRM had evolved over time into a complex patchwork and staff lacked confidence in its outputs.

Rather than jumping straight to a tech fix, we worked closely with stakeholders to understand what outcomes they needed. Where their pain points were and what success would look like. That exploration revealed significant gaps in the underlying technology and infrastructure, prompting a shift to upgrade those systems.

What started as a use case conversation quickly became a strategic driver for broader digital change. The new platform was built not just to replace the old CRM, but to support better data practices, encourage adoption and enable future AI use cases. In effect, the right use case didn’t just solve the one problem. It created the momentum to modernise the technology stack and begin building a more data-savvy culture.

If AI is the answer, what’s the question?

Starting with a use case ensures your investment is grounded in a real-world challenge – not just the promise of future capability.

It helps you answer the essential questions:

By delivering value quickly and scaling from there, you avoid overengineering and increase your odds of long-term success.

Use cases make AI real

Ultimately, AI is only useful if it solves the right problems. That’s why we always advise clients to start with the mission. Focus on real challenges, identify the most valuable use cases and let them guide your strategy.

As James West notes in his blog on building AI readiness in public safety,

Using AI in public safety to solve practical, everyday challenges, like improving police response times or monitoring offenders, can drive real-world change.” 

Treating use cases as a continual cycle of learning, not a tick box exercise is what separates short-term AI pilots from long-term, sustainable success.

That’s how you go from AI ambition to AI impact.

The post Why use cases should be the anchor of your AI strategy appeared first on Made Tech.

Solving these challenges will take more than policy. It’ll take practical tools that support better, faster decision-making. Software can play a key role in helping planning teams access better data, streamline workflows and design services that actually serve the needs of local communities. While it can’t build consensus or set policy, it can make the process of applying those policies more transparent and more consistent.

Local Government Innovation Hackathon

Our friends at the Ministry of Housing, Communities and Local Government (MHCLG) agree. So, at the end of April I spent an enjoyably exhausting couple of days at their Local Government Innovation Hackathon, hosted at Nexus, University of Leeds, exploring some great ideas for building AI-based tools that could be part of a new, more efficient planning system.

Government Digital Service (GDS) and the Incubator for AI organised the event in partnership with the MHCLG Digital Planning Programme and Open Digital Planning. It brought together a wide range of professionals from across the public and private sectors to have a go at tackling some of the most pressing challenges facing the UK’s planning system. The hackathon gave people the chance to explore and experiment with new ways of delivering modern public services.

Critical challenges within the planning system

Wisely, our hosts focused attendees’ attention on a limited number of critical challenges within the planning system. 

1. Housing demand forecasting: Can we develop predictive data models that integrate population trends, migration patterns and economic indicators to improve forecasting? This would help councils plan more accurately for future growth and make sure that public investment goes where it’s needed most.
2. Planning process automation: How do we address the manual, time-consuming processes that hinder planning officers, particularly when assessing complex planning applications? The goal was to look at automation and AI augmentation to speed up application reviews, document processing and predictive maintenance.
3. Public engagement in planning: Can we improve the limited and often ineffective public engagement in planning processes? Is there a way to translate complex planning language and visions into more accessible terms?
4. Infrastructure and housing balance: How do we plan for new homes while balancing infrastructure constraints? This would help planners understand the wider implications of planning decisions.

The judges were looking for 3 key things:

Joanna Averley, Chief Planner at MHCLG, led an intimidatingly A-list judging panel.

Rapid prototyping

Day one kicked off with registration and a welcome session, followed by an overview of the planning system and the challenge statements. Our team was a motley but well-rounded mix, including developers, data scientists, data engineers, testers, IT leadership and planning support.

Our initial discussions focused on identifying our target persona. In other words, who was our application for? We considered developers, planners, central and local government officials and members of the public. Ultimately we decided to build our solution with the local government official in mind. By 3:30 PM, we had a basic outline of our idea, and we began to build our app.

AWS had provided a team on site to help with technical issues, but they also provided some equally welcome refreshment in the evening, which briefly distracted us before a late finish.

Day 2 was an early start and we worked diligently on our application until the 1 PM deadline. The afternoon was dedicated to presentations and judging. 

The presentations were impressive, showcasing a wide range of skills and innovative approaches. The judges were clearly impressed by the effort and ingenuity demonstrated.

Using AI to improve local planning decisions

Our team developed ‘Dwella’. A smart scenario assistant designed to help non-planning specialists (such as local councillors) quickly explore the effects of local changes on housing development plans. We trained our solution specifically on data from the Cotswolds district, but it is adaptable to any planning authority.

Dwella uses Retrieval Augmented Generation techniques to preload locally relevant statistics and policy information into a Large Language Model (LLM), specifically Anthropic Claude Sonnet. This enables a user-friendly, conversational approach to understanding complex planning scenarios. We deployed the application through AWS Bedrock and also had access to forecasting models implemented on AWS Sagemaker. We developed a simple browser-based chat interface to make it easy to use.

Councils could roll out a tool like Dwella, helping save time and resources while giving people more confidence in planning decisions.

Teams demonstrated lots of other great tools at the hackathon. The winner was ‘Clio’. A tool to recover and analyse planning histories for individual sites. This is currently a costly and time-consuming process for planning staff.

What I learned about the planning and housing sector

I’m pretty new to the planning and housing sector and I came away with a number of observations.

1. Efficiency is key: Although the second challenge was very clearly focused on efficiency, almost every project focused on improving it. It’s clear that the planning process is often cumbersome and time-consuming for everyone involved, including planning officers, developers, citizens and decision-makers.
2. Data skills gap: There’s a real need to educate the planning and local government community about what modern data tools can do and how to use them. Above all, we need to create software solutions that are simple, intuitive, easy to learn and clearly deliver immediate benefit to users.
3. Data challenges: The data ecosystem for planning is fragmented and complex. We encountered a wide range of datasets in diverse formats and with diverse standards. Much is unstructured and held within documents. Data discovery is often reliant on lore passed from person to person, although there are valiant attempts such as the Digital Planning Directory which try to address this.

Technically, the main eye-opener for me was Bedrock, the AWS interface for LLMs. I have some experience of building agents and RAG tools, but it was great to see how AWS has provided a useful abstraction layer over the complexities of individual Large Language Models (LLMs). I have some reservations about potential costs and ease of deployment. While it simplifies some aspects, I’m concerned that it might also obscure important configuration details. But we are still very early in the AI revolution and it will be interesting to see how tools like Bedrock evolve.

Hackathon warm-down

It’s called a Hackathon for a reason. Perhaps it wasn’t as gruelling as the London Marathon, but afterwards I felt a happy, exhausted sense of having learned a lot about the planning system and about some tools that might be useful in revolutionising it. Well done, and thank you, to our friends at MHCLG, GDS and i.AI. Let’s do it again, soon.

If you’re curious about how we help government organisations access data more easily and design services that work for real communities, take a look at what Made Tech do with local government here. You might want to browse some of our data and AI case studies too.

The post What happens when you hack the planning system? appeared first on Made Tech.

This is where borrowing from DevOps can help. DevOps practices have transformed how teams build and deploy software – offering the same benefits to data platforms. By integrating automation, continuous deployment and security-by-design principles, you make sure that your data platform remains adaptable and scalable.

Let’s take a look at some key DevOps strategies that can help you get there.

Borrowing best practice from DevOps to build your data platform

By weaving DevOps principles into your build, you set the foundation for a platform that’s not just functional but also secure and ready for change.

The best data platforms aren’t perfect – they’re built to evolve

In summary, it’s not about getting everything perfect upfront. No matter how well you plan, your platform will evolve. Technology changes, use cases shift and new challenges arise. By designing with flexibility in mind, you make it easier to replace or upgrade components without disrupting the entire system. 

Do you want to revisit how to avoid vendor lock-in and remind yourself why it doesn’t pay to gold-plate everything? Take a look at my blogs Building a future-ready data platform and How to choose a flexible tech stack for your data platform . Together, these blogs outline the blueprint for flexibility.

And in a final nod back to my whitepaper Laying the groundwork for AI – although technology plays a critical role in your data maturity journey, it should always be considered alongside your organisation’s use cases and cultural maturity.

The post Creating a flexible data platform with DevOps thinking appeared first on Made Tech.

Q: You started in an infantry role in the Army, what sparked your shift towards digital and technology?

That’s right. I joined the Army as an Infantry Officer – very much at the pointy end of the organisation. Then I was selected for my first technical job around the adoption of Bowman – which was the Army’s adopted digital tactical communications.

I was responsible for its introduction into the first armoured infantry battalion and its first deployment in Iraq. I was then promoted to Major and did a masters degree in information management technology. This set me up to build business applications for the Army.

When it comes to digital, I was responsible for overseeing the build of some of the software that the Army currently uses in its legacy portfolio. Back in 2012, this was the best that was available. Fast forward 12 years and it’s definitely not the best that’s available anymore…

Q: What career path did you take after leaving the Army and how did it lead you to Made Tech?

When I left the Army and before Made Tech, I went into consultancy with quite a generalist delivery approach. But found that when I looked back at the work I’d done, it had all been about digital delivery.

I realised that whether I intended to or not, I found myself to be something of a technologist. That was the work I enjoyed doing and the next logical step for me. 

What I found most exciting about Made Tech was that joining was an opportunity for me to help an organisation that had lots of good experience delivering digital programmes, in what I described as an agile-native environment in government. Being able to bring that into defence organisations along with my experience and different perspectives is something that I think defence really needs. 

Q: What’s your approach to digital in defence?

The reality is that everything’s a computer nowadays. Right from your toaster through to armoured fighting vehicles. For me this is one of the key points where defence should sit up and take notice.

By thinking about capability in terms of the underlying information system within it, you start to separate out the hardware and software elements and the platform and data structures too. All those things we take for granted as digital natives.

Once you start to think in that way, you come up with a very different approach to tackling big problems.

Q: You touched on legacy technology, let’s talk a little bit more about that. 

Legacy creates a problem across defence. For example, when you look at the Army, they still roll around much of their technology in vehicles designed in the 1950s and introduced in the 60s and 70s.

There’s some old bits of kit knocking around. The traditional approach is to use it till it falls apart, then build a new one because that’s what we’ve always done with vehicles. That doesn’t work with digital technology – we need more of an evolutionary approach. 

They didn’t think much about how they would integrate or keep pace with the wider industry and developments in technology. That oversight now creates a big problem in the sector and defence needs to fix it.

Q: Beyond legacy, what other challenges are we seeing in defence? 

Well, we’re now at a nexus point where the expectation of the user – the next generation joining the military or the next generation of civil servants – have expectations of what digital technology should look like. The realities of defence’s digital environment really mismatch those expectations.

That impacts a number of areas. First it’s lower workforce happiness, which feeds into the second one which is that it also impacts productivity. So you’ve got a less productive workforce and not a particularly happy workforce. That makes everything about the business harder to do. 

However, the thing is that having lots of legacy platforms operating in their own silos means that there’s lots of opportunities to improve things. Artificial intelligence (AI) is really hard to apply to defence because their data is not organised in a way that allows them to take advantage of it.

Defence organisations have got to get their digital information systems into a position where they can properly exploit the opportunities available in the wider market – like AI. 

Defence is starting to chip away at this stuff. As they do, the data they release is going to help others to justify doing more. But at the moment, because most haven’t sorted the data side, they find it difficult to justify their work and show the productivity benefits.

Q: How do you think the industry can bring in these new ideas – and implement them well?

One of defence’s biggest challenges is how to get new blood, new organisations and new, innovative ways of doing things into an organisation. If you’re looking at the same old suspects, big primes—and by big primes, I’m talking about the big defence engineering contractors— we’re not seeing the change we want and we’re missing out on innovative talent.

Defence needs to adopt more innovative commercial approaches and dynamic frameworks. This would allow more experimentation, similar to the GDS ways of working. Smaller, innovative companies could then come in and expose the wider market to the true breadth of the defence ecosystem – which those primes currently hide.

This also requires a significant mindset shift. We need to do more in the discovery space and start talking about alphas, minimum viable products, and running betas—all things we’re used to in many other areas of government.

We just need to accelerate that thinking into not just the back-office of defence, but also into battlefield capabilities. 

Q: What strategic shifts could defence organisations introduce to optimise their approach to digital?

Defence must focus on services, not platforms. Currently, they prioritise large platform procurement in their discussions. Their system is designed to build these platforms. And again, this design, rooted in old manual processes, is part of the problem.

How did you build a tank in the 1950s? You do it like this.

That’s how procurement systems are set up in defence. But that doesn’t work if you want to evergreen an information system. You’ve got to think about roadmaps rather than detailed requirements documents. 

This allows teams to iteratively work to set up a minimum viable product. You’re then at the point where you can deliver something and iteratively deliver all those ‘nice to have’ requirements afterwards. That way we get working software in the hands of the user much more quickly.

We can keep improving that software so they’re not paying for a new platform in 10 years time. By continually improving and updating the platform you get better and better software and a better user experience.

This requires a change to the procurement system and a change to the way defence thinks about projects and programmes. It needs to be much more about service management and incremental upgrades to get something out in the world much quicker. 

In this post I mention the need to digital information systems into a position to properly explore opportunities like AI. If you’re looking for a framework to help you navigate those challenges, download our whitepaper, Laying the groundwork for AI.

The post The future of defence is digital appeared first on Made Tech.