If you lead Product or sit as a Senior Responsible Owner (SRO) in the UK public sector, you’ve probably sat in a meeting recently where someone demanded ‘more innovation’. You may have even been the one demanding it: we all want innovation.

But a year into most projects, leaders often find themselves looking at one of two scenarios:

The Pedestrian Solution: A new web form sitting on top of the exact same broken, legacy back-end process. A lot of work, but no real efficiency gains.

The Delivery Swamp: An ambitious initiative completely bogged down in delivery, flagged ‘Amber/Red’ by the Infrastructure and Projects Authority (IPA), trapped in an endless cycle of assurance gates, 100-page risk logs, and scope creep.

It’s a familiar failure pattern. Year after year, the National Audit Office (NAO) and the Public Accounts Committee (PAC) publish reports echoing the same structural diagnosis: government digital programmes rarely fail due to a lack of technical ambition. They fail because of optimism bias, rigid procurement, heavy-handed governance, and losing sight of underlying user needs under the weight of burdensome feature requirements.

No matter how smart or motivated the team, there are three traps that they often fall into.

Trap 1: The ‘innovation’ banana skin

The first trap is that ‘innovation’ is a slippery word. We’re not sure what it is, we hope we know it when we see it.

When we demand innovation, we’re rarely clear about what we’re asking for. Do we want a slightly better web portal, or do we want to automate entire casework decisions using machine learning? Those two things require fundamentally different resources, mindsets, and governance structures.

To set up a project for innovation we need to be clear about what we mean. We can do that by asking: are we serving an existing need, with existing tech; or a new need with new tech?

1. Incremental Innovation:
   • What it is: Small improvements to something that already works.
     Examples: Digitising a paper process, reducing fields on a form, or improving content clarity.
   • Governance needed: Standard Agile delivery, standard GDS Service Standard checks.

2. Sustaining & Architectural Innovation:
   • What it is: Improvements that set the stage for future success.
   • Examples: Moving legacy databases to cloud infrastructure, breaking up monolithic supplier contracts, or adopting API-first architectures.
   • Governance needed: Requires technical patience and decoupling from immediate, flashy front-end ROI.

3. Disruptive Innovation:
   • What it is: Reframing an existing problem, and applying existing technology.
   • Examples: The early days of GOV.UK Notify—a simple, transformative way for the government to communicate, built on standard, existing tech.
   • Governance needed: Focus heavily on changing user behavior and policy operations, rather than tech build.

4. Radical Innovation:
   • What it is: Fundamental re-thinking of service delivery.
   • Examples: Think ‘using automated eligibility engines to eliminate the need for citizens to apply for benefits altogether’.
   • Governance needed: Requires “sandbox” rules, relaxed business case gates, and a genuine, institutional tolerance for early failure.

In other words, each type of innovation requires a different approach to risk and governance. 

In practice, government departments don’t make those choices. They routinely subject disruptive ideas to the most rigid Green Book governance that is designed for predictable infrastructure. Demanding detailed upfront certainty on scope and return crushes innovation and delivers pedestrian, low-risk solutions.

Trap 2: Focussing on ‘materials’ instead of outcomes

There’s a second reason government innovation goes off the rails: we confuse materials with outcomes.

Tech-driven innovation is notoriously hit-and-miss. Outcome-driven (User-Centered Design) innovation hits the target consistently.

Decades of delivery data back this up. The Standish Group’s global tracking of over 50,000 IT projects shows that nearly 65% of features built in traditional tech-first projects are rarely or never used. Meanwhile, studies by McKinsey consistently show that 70% of digital transformations fail to hit their targets—not because the software failed, but because the team built a solution for a problem the user didn’t actually have.

Why? Because technology based innovation focuses on the materials (cloud platforms, AI, blockchain, low-code tools). User-Centered Design focuses on the outcome (solving a real human problem for a citizen or a caseworker).

Focusing on materials is like buying a pile of expensive bricks and tools without knowing what house you want to build. You end up with costly white elephants looking for a problem to solve. It’s a classic trap: buying an AI contract or a new tech platform before understanding what public value it is meant to unlock.

Technology can put new possibilities in reach, but it’s User Centred Design that turns possibility into public value. Successful innovation begins with a laser focus on the user.

Trap 3: The wrong constraints

When projects start to flounder, the instinct in government is often to throw more money, stakeholders, and features at the problem.

This is entirely backward. True innovation rarely comes from unlimited budgets, bloated requirements; it comes from demanding radical outcomes with tightly constrained resources.

Scarcity forces focus. When resources are constrained, teams are stripped of the luxury of over-engineering. They cannot build every ‘nice-to-have’ requirement demanded by internal committees. They are forced to look at the raw, underlying user need and find the leanest possible way to achieve it.

Contrast this with procedural constraints:

• Resource constraints (Good): Tight budgets, small cross-functional teams, and aggressive timeframes force focus, speed, and ruthless prioritization.
• Procedural constraints (Bad): Endless sign-off layers, mandatory feature parity with 20-year-old legacy systems, and risk avoidance force conformity.

Procedural constraints force outcomes to look like whatever came before. Resource constraints force people to find a new way.

Saying ‘no’

To create the conditions for innovation, you have to be willing to say ‘no’ to stakeholders.

Government projects get weighed down because every department, policy team, and oversight group wants their specific requirement baked into the new system. The result is a camel—a horse designed by committee.

If you want an innovative outcome, you need to establish what doesn’t matter. You need to be prepared to descope legacy features, ignore low-value stakeholder requests, and actively build “governance cover” for your delivery teams so they can experiment, learn, and iterate.

The Innovation Checklist

Before you write your next business case or sign off on your next delivery roadmap, sit down with your leadership team and ask four questions:

1. What type of innovation are we actually asking for? Are we making an incremental tweak, re-platforming architecture, or trying to disrupt a service model?
2. Does our governance match the risk profile? Are we forcing a flexible, exploratory project through a rigid, up-front business case process?
3. Are we focussing on technology or outcomes? Are we falling in love with a shiny new technology, or are we obsessed with solving an underlying user problem?
4. What are we prepared not to do? What stakeholder requirements, legacy rules, or non-essential features are we actively willing to jettison to keep the team fast and focused?

If you can answer those questions honestly, you’ll stop chasing the illusion of ‘innovation’—and start delivering real public value.

The post Escaping the ‘Innovation’ trap: setting up projects to deliver real impact appeared first on Made Tech.

There is plenty of appetite to use AI at the moment, both from clients and from the people delivering projects. But when somebody actually asks for permission to use it, the safest answer can still be no.

That is often because the person making the decision doesn’t have a straightforward way to understand the risks involved. And that was the starting point for Made Tech’s new AI Risk Assessment Framework.

We wanted something that would help teams work through what the AI risks actually are, how serious they might be and what could be done about them. Importantly, it also gives the person signing it off something useful to make a decision with.

Different uses, different risks

Using AI to analyse some code or getting it to process research transcripts is very different from building an AI-enabled feature into a public service. The risks change depending on what you are doing, what information is involved and how much freedom you are giving the AI to act.

The framework covers common uses including software development, live service support, user research, design and business analysis. Teams document what information they’re sharing, check the tool they intend to use and work through the eight risk areas, covering things such as data leakage, hallucinations, bias, security and licensing.

There’s also a less obvious risk around people becoming over-reliant on AI. If the answer to every problem becomes asking an AI tool to produce something, people can miss the learning that comes from working things out themselves.

Actually writing the risk down

For each relevant risk, the team looks at the likelihood of something going wrong and the impact if it did. They consider how much autonomy the AI has, decide what safeguards are needed and then assess the risk that remains.

It sounds quite involved, but a straightforward assessment can be worked through relatively quickly. AI itself can even help teams think through some of the questions.

The important bit is that there’s a record of the thinking. Instead of asking someone to approve something they can’t really see, teams can show them the risks, explain what they’re doing about them and address any concerns.

It’s useful further down the line too. If a service assessment asks what has been done about hallucinations, for example, the team can show its assessment and explain the mitigations. There’s a big difference between saying something will probably be fine and demonstrating that you’ve actually thought about it.

Built to be used

We’ve deliberately made this a practical framework rather than an abstract piece of AI policy. It comes from the reality of trying to use AI on government projects, where teams want to make progress but also need to be sure they’re not introducing risks they haven’t properly understood.

The framework is already being used on project work and we’re starting to use it more widely across Made Tech. We’ve also released it under an open licence so other government departments, suppliers and delivery teams can pick it up and use it themselves.

This is the first version, and we expect it to change as AI evolves and we learn more. We’d welcome feedback, critique and suggestions from people using it on their own projects, particularly if they find things we’ve missed or ways of making it more useful.

The post A practical way to assess AI risk on government projects appeared first on Made Tech.

Discovery and Alpha have always existed for a reason. They give multidisciplinary teams the space to understand users, test assumptions, explore technical options and build enough confidence to decide what comes next. Good agile delivery has never been about moving quickly for the sake of it. It’s about reducing uncertainty before committing significant time and investment.

What agentic AI is beginning to change is not the purpose of those phases, but the pace at which parts of them can happen.

At Made Tech, we’re seeing opportunities to compress Discovery and Alpha from the 12 to 20 weeks many organisations have become accustomed to, towards eight to 12 weeks. That isn’t because teams are skipping research or cutting corners. It’s because AI can help complete some of the most time-consuming activities much more efficiently, allowing teams to move more quickly from gathering information to testing ideas.

That’s an important distinction because it challenges one of the biggest misconceptions surrounding AI.

Much of the conversation focuses on automation or replacing people. Our experience has been different. The greatest value comes from removing the waiting. Activities such as synthesising research, analysing technical options, generating documentation and producing early prototypes can now happen far more quickly, giving teams more time to engage users, challenge assumptions and iterate solutions.

In other words, AI isn’t replacing agile delivery. It’s compressing it.

Faster delivery doesn’t mean less discovery

There’s a temptation to assume that if Discovery and Alpha become shorter, teams must be doing less work. In reality, the opposite should be true.

The activities that matter most in Discovery have never been writing documents or creating slide decks. They are understanding users, testing assumptions and building confidence that a team is solving the right problem before moving into delivery. Agentic AI can help remove much of the administrative effort that surrounds those activities, allowing teams to spend more time where human insight adds the greatest value.

Rather than investing weeks pulling information together, delivery teams can move more quickly into conversations with users, explore a wider range of technical options and iterate solutions sooner. Shorter delivery phases should create more opportunities for learning, not fewer.

That’s why I see AI as an evolution of agile rather than a replacement for it. The principles remain exactly the same. We are simply reducing the time between learning, deciding and delivering.

The bottleneck is no longer the technology

As delivery accelerates, another challenge begins to emerge.

For many organisations, the limiting factor won’t be whether AI is capable of producing better outputs more quickly. It will be whether leadership, governance and decision-making can keep pace.

If a delivery team can reach an evidence-based recommendation in half the time, but approvals, funding decisions or governance reviews still follow the same timetable, the overall pace of delivery changes very little. The bottleneck simply moves elsewhere.

Leading public sector organisations are beginning to recognise that adopting agentic AI isn’t just about introducing new technology. It also requires organisations to rethink how decisions are made, how multidisciplinary teams are empowered and how governance supports rapid learning rather than becoming another queue in the process.

That’s a much bigger organisational challenge than selecting the right AI tool.

Human judgement becomes even more valuable

The more capable AI becomes, the more valuable human judgement becomes alongside it.

Agentic AI can analyse research, compare options and generate documentation at remarkable speed. What it cannot do is understand organisational context, balance competing priorities or build trust with users and stakeholders. Those remain fundamentally human responsibilities.

The same applies to service design. AI can help teams reach better-informed starting points, but it cannot replace the conversations that uncover unmet needs, challenge assumptions or explain why a service works the way it does.

Our experience modernising legacy systems has reinforced that lesson. Technology rarely tells the whole story. Every organisation develops workarounds, informal processes and operational knowledge that sit outside the system itself. AI can help explain the code, but it still takes people to understand how services actually operate.

That’s why experienced multidisciplinary teams remain at the centre of successful digital delivery. AI makes those teams more effective. It doesn’t make them less necessary.

A different way of thinking about delivery

The organisations that benefit most from agentic AI are unlikely to be those that simply deploy new tools and expect delivery to accelerate automatically.

The real opportunity lies in changing how teams work. If research can be synthesised in hours rather than days, if prototypes can be generated in a single sprint and if technical options can be explored far more quickly, organisations also need to become better at making decisions, testing ideas and acting on evidence.

For smaller, agile delivery partners like Made Tech, that shift plays to our strengths. We’ve always believed that better public services come from empowered multidisciplinary teams, rapid feedback and continuous learning. Agentic AI doesn’t replace those principles. It reinforces them by removing much of the friction that has traditionally slowed delivery down.

The organisations that will benefit most won’t necessarily be those with access to the newest AI tools. They’ll be the ones prepared to evolve their culture, governance and ways of working alongside the technology. That’s how faster delivery becomes better delivery, and how agentic AI becomes more than just another productivity tool. It’s an opportunity to rethink how digital services are designed, delivered and continuously improved. That’s at the heart of what Made Tech is all about.

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

The post Taking advantage of the next acceleration curve appeared first on Made Tech.

If you’re a Senior Responsible Owner (SRO) or stakeholder, then keeping a digital project on track can feel frustrating and confusing at times. Projects can become bogged down, take wrong turns, or lose sight of the user and it’s hard to spot when things start to go off course.

Governance meetings ought to help but they’re infrequent and one step removed from the activity. The real action happens outside of those meetings.

What’s more, when one sees a project is going off track one’s instinct is to increase control and governance—make the requirements even more specific and demand even more detailed progress reports. But specific requirements just lead to questions and pushback from the team. Detailed reporting takes the team away from delivery. Admin instead of action.

Attempting to fix delivery only pushes it further off track.

Done properly, Product Management can fix those problems, delivering outcomes without killing agility. It does that by providing clear direction, ensuring good judgement, and keeping the focus on users.

Signs there’s a lack of direction

1. The team is busy but not moving

Digital teams are rarely short of activity. Sprints are running, boards are full and people are solving difficult problems, but it is perfectly possible for everyone to have plenty to do without the programme becoming any closer to releasing something useful.

Usually, this is not about effort. It is about nobody having identified the spine of the service. What must work first? What would a useful initial version look like? Which work moves the programme forward, and which can wait?

A good product manager helps the team find its focus. It’s about knowing that the car needs an engine and wheels – the decision about what colour to paint it can come later.

2. Nobody is telling the story upwards

As a stakeholder, you need more than milestones and status reports. You need to understand what is being built, why choices have been made and how the work contributes to the outcome for which they are accountable.

When that story is missing, the delivery can feel disjointed and irrelevant.

Imagine somebody is rewiring your house and you cannot see much progress, so you begin asking what every cable does. The electrician can explain every connection, but you may still have no idea whether the lights will work.

The same happens in digital projects. Without a strong vision, a tool like a CRM can easily become a collection of irritating and complex forms that staff must complete. Admin for admin’s sake. A product vision like ‘design the hive mind where colleagues collaborate to make customer interactions feel seamless and effortless’ brings to life the ‘why’ behind the ‘what’. The forms remain, but now the team is focussed on making them useful and usable, and stakeholders can see the rationale behind design decisions.

3. Requirements are treated as fixed

Many programmes begin with requirements shaped through policy work, a business case or procurement completed months or years earlier. Those requirements matter, but they are not the same thing as the outcome.

Technology develops, operating conditions change and research reveals things that were not known when the specification was written. Teams may also discover that a requirement is expensive, impractical or simply not useful. Meanwhile, there may be new opportunities to deliver something that is relevant today rather than meet the requirement of a year ago.

A product manager keeps returning to the intention behind the requirement. Why is it there? What problem was it meant to solve? What do we now know that we did not know before?

The important question is not simply whether the team has delivered what the document says. It is whether it has delivered to the intention. That does not mean reopening every decision, but it does mean avoiding the faithful delivery of something that sounded plausible 18 months ago and is out of date when it reaches the public.

Signs that no one is exercising judgement

4. A technology decision has not been stress-tested

Technology choices can gather momentum quickly. A platform looks promising, a supplier proposes an established solution or a team becomes enthusiastic about an approach. Once time and money have been committed, questioning it becomes harder.

A product manager is not there to overrule architects or technical specialists. Their role is to make sure the important questions are asked before the programme becomes dependent on the answer. Has the approach been tested where it will operate? Will it work with existing systems and data? Have alternatives been explored? What evidence would make the team change its mind?

A solution can look credible in isolation and still prove unworkable in practice. Finding that out early is not failure. It is useful information, provided the programme responds to it.

5. Risk belongs to everybody and nobody

Risk registers are valuable, but they rely on people feeling able to raise the risk. In a pressured programme, it can be difficult to say that the date is unrealistic, the supplier relationship is becoming difficult, or the chosen technology may not support the service.

The longer confidence in the plan has been maintained, the harder it becomes to challenge. Stakeholders may respond by holding the team more tightly to the original dates and requirements, which can make people even less likely to surface problems while there is still time to act.

A good product manager helps create a healthier dynamic. It’s not useful to discuss who made the wrong call six months ago, but what the team now knows and what the best next decision is. By prioritising effectively, managing dependencies, or making a change of direction they can pro-actively manage risk.

6. Suppliers are delivering the contract, not the outcome

Contracts need to define responsibilities and deliverables, but they cannot fully describe a service that has not yet been built.

Over time, an outcome discussed during procurement can become a series of tasks delivered to the letter. Each organisation may complete its part while the programme as a whole moves no closer to a coherent service.

It is like delivering a pile of bricks to the front door and explaining that nobody said anything about building the wall. The contractual output may have been met, but it is not the outcome anybody wanted.

Commercial and legal expertise remain essential. Product management complements them by keeping suppliers, internal teams and operational partners connected to a shared goal. The question is not only whether the contract is being delivered, but whether what is being delivered still serves the outcome.

Signs the project is losing legitimacy

7. The service passes the assessment but fails the frontline test

The ultimate test of legitimacy is: does it serve the needs of the members of the public or organisations that need to interact with the state?

A programme can pass formal gates, meet contractual commitments and complete its roadmap while still producing an experience that is no better than the one it replaced.

Service assessments provide important scrutiny, but they happen at particular moments. A good product manager keeps absorbing user research and asking what it means throughout delivery, rather than treating research as something that happened during discovery and can now be filed away.

They also look beyond the person directly using the screen. In the CRM example, the immediate user may be a civil servant entering information, but the ultimate beneficiary is the citizen making contact. If the system works well, they receive a more consistent response, encounter fewer errors and do not have to repeat their story.

The experience of frontline staff matters too. Tools that support a good service make the work feel meaningful, while a process that frustrates the public frustrates the people delivering it as well.

The real test is not simply whether the product has passed an assessment. It is whether the service works for everyone who depends on it.

Owning the outcome continuously

If those problems feel familiar to you, that’s not a coincidence. Often, product managers shrink to manage documentation rather than outcomes.

Good product management isn’t about paperwork. Backlogs, roadmaps, objectives and research findings all matter, but a focus on outcomes is what keeps projects on track.

Of course projects are team efforts. A good delivery manager makes sure the process is followed. A good PMO has your back when it comes to reporting. But a good product manager is there to make sure the right outcomes get delivered.

If you’re experiencing more than one of those seven problems, try asking this question in your next programme board: “Who in this room owns the outcome, not just their piece of it?” If the honest answer is “no one,” then it’s time to upgrade your product management.

If you’re interested in learning more about keeping your digital project on track, please get in touch via our website, or find out more about Digital Service Delivery from Made Tech.

The post Governance meetings aren’t enough to fix your digital delivery. Here’s what else you need. appeared first on Made Tech.

Public sector organisations are under constant pressure to innovate, modernise services and explore new ways of working. But across government, there’s a growing frustration with ideas that never seem to make it beyond the proof of concept stage.

Pilots are launched, prototypes are tested and early promise gets people excited, only for momentum to stall before anything reaches production. Sometimes that creates scepticism around innovation itself. If services never go live, what was the point?

According to Ben Pirt, Principal Technologist at Made Tech, and Geraldine Mathews, Made Tech’s Client Partner, the answer is more complicated than simply labelling these projects failures.

“Some proof of concepts should bring a stop to a process,” says Ben. “That is exactly what alpha is there for: testing whether something genuinely meets a need before too much time, money or complexity builds around it. The bigger challenge is making sure that the ideas which should move forward are designed for real-world delivery from the start.

“That means building earlier, testing with users sooner and thinking about integration, operational pressures and delivery constraints long before a service reaches production.”

Ben continues: “The whole point of the process is to have some stage gates so you can make sensible decisions as you go. People have been burned by the old-school approach of spending a long time building something and then getting to the end and realising it wasn’t actually what was needed, or it didn’t fulfil the right need, or legislation had changed. This process exists so you can learn that earlier.”

Geraldine and Ben agree that the proof of concept process gives teams the chance to test whether something genuinely meets a need before too much time, money or complexity builds around it.

“Alpha is definitely about identifying that there is a need and identifying the right shape of the thing to build,” Geraldine explains. “By the time you get to beta, you should know that it’s fulfilling a need. Beta should be more about rolling something out gradually and learning the things you can’t know until real people start using it.”

That distinction matters because it changes how teams think about progress. A decision not to move forward after testing is not necessarily a failed project. Often, it is evidence that the process is doing exactly what it was designed to do.

Why good ideas still struggle to become live services

Where things become more difficult is in the gap between a promising proof of concept and a service that can operate successfully in the real world. In government, even relatively straightforward services rarely exist in isolation.

“You almost never build a system that doesn’t integrate somewhere else,” Geraldine says. “Even if it’s something quite small, there’s usually another dependency, another team, another platform involved. That’s just the nature of government services.”

Those dependencies can quickly become the real challenge. A proof of concept may demonstrate clear value, users may respond positively and teams may want to move ahead, but the surrounding environment is not always ready to support it.

“Sometimes it’s operational overload,” Geraldine explains. “Teams just can’t take something else on right now because they don’t have enough people. We’re seeing that all over government at the moment. In other cases, it’s integration, data sharing or legacy systems. Somebody can have a really good proof of concept that would genuinely help citizens or caseworkers, but taking it live becomes difficult because there are too many dependencies in other places.”

Building earlier and learning faster

That complexity is one reason why Made Tech prefers to get tangible services in front of users early rather than spending long periods in theory or planning.

“We don’t stay on paper for a long time,” Geraldine says. “We build, we show, we go.”

That approach reflects a broader shift happening across delivery teams. Expectations have changed. Clients increasingly expect to see working services earlier in the process rather than static wireframes or long discovery documents.

“I think it’s the expectation that things can be done a lot faster now,” Geraldine says. “Clients are hearing that. They’re going to conferences, they’re reading about AI and rapid prototyping and they know it’s possible to move more quickly. It’s not just mock-ups on a wireframe anymore.”

For Ben, this comes back to a simple principle: learning happens through doing.

“A lot of big consultancies became known for massive discoveries and huge amounts of upfront thinking,” he says. “But you don’t really know if any of it is right until you hit the ground and start testing with real people. You can plan and think as much as you like, but until people are actually using something, it’s all still theoretical.”

Why Made Tech does not believe in wasteful delivery

That same mindset shapes how Made Tech thinks about alpha delivery itself. There is a long-standing belief in some delivery circles that whatever gets built during alpha should be disposable. Ben understands the reasoning behind that idea, but believes it can sometimes create unnecessary waste.

“The intention behind it is right,” he says. “You don’t want people becoming too attached to early decisions because they’ve already invested time in them. But if you’re building something that people are genuinely going to use for testing, it still needs proper infrastructure, it still needs to be secure and it still needs to meet certain quality thresholds. Once you’ve done that, throwing it away and starting again can feel pretty wasteful.”

Instead, the focus should be on remaining flexible enough to change direction when needed, rather than assuming everything built early on must eventually be discarded.

A pragmatic approach to government delivery

That pragmatism comes through repeatedly in how both Ben and Geraldine describe delivery. Rather than trying to fully untangle every complexity at the outset, the focus is on finding something meaningful that can be understood, built and tested quickly.

“A lot of government services have evolved over years and years,” Geraldine says. “Policy is layered, legislation changes and nobody completely understands every part of it. We’re probably better at going in, finding something smaller that we do understand and showing something tangible around that, whether it’s service design or a front end. Then we work our way through the complexity instead of getting stuck in it.”

That practical approach also shapes how Made Tech works with clients more generally. Ben describes it as a willingness to adapt to whatever the project actually needs rather than rigidly sticking to an original scope.

“We’ve historically been good at just doing what needs doing,” he says. “If the shape of the project changes halfway through, then fine, we change with it. It’s a very pragmatic approach.”

What comes through in the conversation is a practical view of delivery. Less focus on innovation for its own sake, more focus on getting something useful in front of users early and learning from it.

The important thing is not that every proof of concept reaches production. It’s more about ensuring that teams learn, early enough, to make the right decision about what happens next.

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

The post Embracing proof of concept to deliver transformation faster appeared first on Made Tech.

A Day at Made Tech: What It’s Really Like

A typical day at Made Tech starts with a calm but focused atmosphere. I’d arrive, settle in, and check my tasks for the day. The team always made space for me, and even though I was a student, I felt like a real contributor. Mornings often began with stand‑ups — short meetings where everyone shared what they were working on. This was one of the first surprises for me: how much communication matters in tech. It’s not just coding in silence; it’s constant collaboration.

After stand‑up, I’d dive into my tasks. Some days I was writing Python code for the login system. Other days I was testing endpoints, fixing bugs, or improving the database. I learned quickly that real‑world coding is less about writing perfect code the first time and more about iterating, testing, and refining. The team encouraged me to ask questions, and every answer helped me understand not just what to do, but why it mattered.

One of the most surprising things I learned was how much consultants think about users. Even when building something simple, the question was always: “How will this help the user?” That mindset changed how I approached my work. Instead of just making features function, I started thinking about clarity, security, and long‑term maintainability. Lunch breaks were relaxed and social — a chance to talk about tech, career paths, or even completely unrelated topics. These conversations helped me understand the culture of tech teams: supportive, curious, and always learning.

Afternoons were usually focused work time. I’d continue building features, updating documentation, or reviewing feedback. I learned how to manage my time, how to stay organised, and how to keep track of tasks using tools like GitHub. Seeing my code pushed to a real repository was a moment of pride — it made everything feel real.By the end of the day, I’d reflect on what I learned. Every day brought something new: a concept, a tool, a technique, or a piece of advice. That constant learning is what makes tech exciting.

🎓 Advice for Future T ‑ Level Students

If I could give one piece of advice, it would be this: don’t be afraid to ask questions. Tech is a team sport, and learning from others is part of the job. Be curious, be open, and take every opportunity to try something new. Your placement is not just about completing tasks — it’s about discovering how you work, how you learn, and how you fit into the world of digital consultancy.

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

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.

What does a typical morning look like? 

As a student, it’s important to gain a variety of skills during your college years to help prepare for adulthood. Being part of the Made Tech team has allowed me to experience so much and every working day is different, where I am consistently learning something new. Starting a work placement as a student can feel both exciting and nerve-wracking, but each day brings new opportunities to learn and grow. 

I typically start my day at 9:30am, whether I am working online or in person. I begin by checking my emails and Slack for any updates, which helps me stay organised and prepared for the day ahead. We usually start our morning with a catch-up session, where we talk about what we’ve done over the week. At the end of each week, we complete a journal and an evaluation reflecting on the skills we develop.

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

One of the most surprising things I learned about tech is how much teamwork is involved. Teamwork and collaboration are essential to share ideas, fix problems and meet deadlines. 

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

For the next group of students, I would advise them to be confident and ask questions. At first, it can feel intimidating being in a professional environment; however, everyone understands that you’re here to learn. At MadeTech, one of the key values is continuous learning, whether it is a personal skill or a technical one. I would also advise staying organised and managing your time well. At first, it may feel overwhelming balancing work, college, and personal life, but remember you can always speak to your manager and teachers for support. 

Overall, my experience here has been extremely valuable. I have developed many personal and technical skills through programming projects such as the NASA Space Apps Challenge, which gave me a better understanding of how collaboration works in a real programming environment. The skills I’ve developed through those projects have helped me perform better in my end-of-year exam and will continue to support me in my future career.

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

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.