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.

Update: Phase 2 of Awaab’s Law comes into force on 30 November 2026. That date is now confirmed in MHCLG guidance for social landlords published in July 2026, alongside the draft Amendment Regulations that bring the new hazard categories into scope. The speculation is over. Housing providers have a fixed deadline – and at the time of writing, roughly 19 weeks to hit it.

Phase 1 of Awaab’s Law came into force in October 2025. Most social landlords spent the preceding months scrambling to get contact centre scripts in order, key processes defined, and supporting software tested and ready. Some were ahead of the game, many were not (based on the conversations the Made Tech team have had over the last few months).

Phase 2 is going to be harder.

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

What is Awaab’s Law?

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

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

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

Phase 2 extends those same obligations to a wider set of hazard categories from 30 November 2026. Phase 3 will follow at a date yet to be confirmed, covering all remaining Housing Health and Safety Rating System (HHSRS) hazards except overcrowding.

Which hazards does Phase 2 cover?

The July 2026 guidance sets out the categories that become “significant hazards” from 30 November 2026, joining damp and mould (already in scope from Phase 1):

What Phase 2 means for social landlords

1. The admin burden is going to get heavier

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

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

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

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

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

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

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

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

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

3. Preparing for Phase 2 needs an operational owner

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

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

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

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

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

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

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

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

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

What to do before 30 November

The guessing game is over. From mid-July, providers have about 19 weeks – and once you subtract summer leave, board cycles, and the run-up itself, meaningfully less. Here’s where to focus, in order:

• Now: audit your team structure. For each Phase 2 hazard category, who in your organisation would own the response? Is that clear? Do they know?
• Now: assign a programme lead. Someone with the authority to convene the right teams and the mandate to make process decisions. Every week without one is a week of drift.
• By early autumn: identify and close your process gaps. Where Phase 1 required you to build a new process, Phase 2 will require more. Map what you have. Name what you don’t. Pay particular attention to the written summary workflow and your no-access procedure – both now have explicit expectations in the guidance.
• By early autumn: define your relocation criteria. Don’t leave this until a case forces the issue. A short internal policy – what triggers a relocation, how it’s approved, and how it’s documented – will save significant time
• Before 30 November: review your open cases in Phase 2 categories. Under the transitional arrangements, a known hazard reported again after commencement starts the clocks. Your backlog is not grandfathered.
• Before 30 November: test the whole thing end to end. Run a Phase 2 case through your process on paper before a real one arrives with a statutory deadline attached

How Made Tech’s case management software helps

The Awaab’s Law Phase 1 Test and Learn research report, commissioned by MHCLG and delivered by Verian, found that “case-management has emerged as a best-practice approach for dealing with complex hazards” – landlords shifting towards “end-to-end case management” and away from “a purely task-based repairs model.” A hazard isn’t a single job; it’s a lifecycle – reported, investigated, escalated, remediated, evidenced, closed – and job-based, works-order systems fragment that lifecycle instead of tracking it.

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

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

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

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

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

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

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

User needs meet policy and operational reality

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

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

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

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

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

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

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

Why early delivery matters

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

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

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

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

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

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

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

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

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

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

Adoption is the real test

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

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

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

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

Process or impact?

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

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

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

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

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

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

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

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

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

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

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

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