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.

Content designers have a few tools that we, along with other user-centred design colleagues, can use to help the process along.

Language definition workshop

Sometimes, when a team begins working on a new service, everyone uses different words and phrases to describe it. Some people might talk about the service going live, while others will use the term ” launching the service. Both mean the same thing.

Or, everyone might use the same terms, but with a different mental model of what they mean. Some people think precipitation refers only to rain, while others believe it can also mean rain, snow, or hail.

This can lead to confusion or differences in expectations. As Abby Covert puts it, language matters.

The workshop

1. Research how language is already used in similar services or situations.  Can you find any patterns or consistency?
2. Discuss what you want users and stakeholders to think of when they hear the words or phrases you are considering.
3. Agree on definitions for words and phrases that you wish to test with users to see if they understand them in the same way.

After testing with users, you can refine and rework the definitions based on what you learned from the testing. Working like this should bring:

Consensus

When the team discusses the meaning of the words, it helps them clarify the purpose and scope of the service.  Consensus enables everyone to communicate in the same terms, eliminating confusion.  

Clarity

Another benefit of being really clear about language is that you get consistency within the service.  A good team understanding can be refined using insights gained from user research and testing. This helps to make the service content and communications user-centred, clear and consistent.

Communication

The team can set and manage stakeholder expectations, ensuring consistency in their communication of progress. Agreeing on clear, consistent language helps to keep everyone on the same page. 

Lexicon

Recording language decisions

It’s no use spending lots of time defining the language your team is going to use if everyone forgets it straightaway. You need a record.

The Cambridge Dictionary defines a lexicon as “(a list of) all the words used in a particular language or subject, or a dictionary”. 

A living document

A lexicon is a living record of the words the team uses. It should grow and change as the project progresses. Store it centrally so that everyone has access to it. All team members should be able to refer to it, add to it, and edit it.

It should help the team to stay on track with each other linguistically and avoid confusion or differing interpretations.

Question Protocol

The cost of asking questions

Many services involve asking the user questions to gather information. We must ask the right questions and only request what we genuinely need. 

As Caroline Jarrett says, “Every question has a cost”. Asking too many questions, unnecessary questions, or overly invasive questions will lose your users’ goodwill.  This can lead to dropouts or poor data.

Questions to ask ourselves

A question protocol is a tool that helps narrow down what you actually need to ask. 

Look at each question and ask yourself about the value it gives:

• who uses the data?
• how do they use it?
• is it necessary to ask for this data?
• is the question mandatory or optional?
• what happens if the user puts in nonsense to get through the form?
• do we have this information already?

Benefits

Bringing form design and data collection into sharp focus helps to make better decisions. This gives the following benefits:

• reduce overheads by not collecting and storing unnecessary information
  • storing data is costly. Why store something you don’t need?
• ensure the integrity of the data you collect
  • making it easy for users means they are more likely to give you accurate information
• avoiding causing offence or unnecessary burden means that users are more likely to answer all the questions
• pinpoint whether asking a particular question helps or hinders user engagement
  • look for patterns where users drop out after a specific question, consistently miss a question or give false information
• find ways to reduce the burden on users
  • make questions easier to understand
  • tell users early in the process what information they might need to gather to answer the questions
  • avoid repeating questions by bringing through information that you already have
• avoid causing harm or offence to users
  • only ask for information that might be difficult or personal when there is a clear need
  • be clear with users why you are asking for it
  • tell them how you will use it and who will see it
  • avoid being reductive, use inclusive language for sensitive topics or vulnerable user groups
  • use a trauma-informed approach

Content Design at Made Tech

Content Designers aren’t just here to write about decisions that were made before we were brought in. Involve us from the start. The linguistic tools mentioned in this blog are just part of the range of skills we bring. Making decisions can be hard, but we’re here to help.

The post 3 simple ways to use language to help decision-making appeared first on Made Tech.

In this blog, I’ll explore the hidden costs of avoiding SLAs and the dangers of over-engineering for unattainable uptime. I’ll look at how a shift in mindset can help teams become more comfortable with being measured and some practical steps that can improve both service reliability and user satisfaction. Read on to discover how a more mature approach to SLAs can transform the way we deliver services and better serve the British public.

SLA avoidance

Historically, SLAs have been used as a commercial stick to penalise teams that don’t meet their commitments. Financial penalties for failing to meet an SLA have conditioned teams to either avoid them or insist on SLAs that don’t truly reflect service availability. Instead, teams fall back on metrics like bug report response times or processing a set number of tasks – neither of which benefits the users or adds business value. 

Are we overspending for uptime?

When there’s no SLA, the idea  that a service should have 100% uptime fills the vacuum. But aiming for 100% availability often results in excessive redundancy, such as running 3 servers instead of 2. Cloud providers are more than happy to charge for extra infrastructure, even if there is no need. Does the value of the service really justify tripling the cost? And what’s worse, redundancy doesn’t always guarantee uptime. A recent outage for a cloud provider across 2 of its UK data centres, meant that the rush to its third data centre overloaded capacity, causing widespread failures.

Moreover, redundancy doesn’t just increase costs linearly. For example, running servers across multiple data centres incurs fees for data transfer between locations. I once worked in a team that ran a database across 3 data centres, but the constant data shuffling between them to ensure redundancy, added around £80k in unnecessary costs in just one month and when 2 of the data centres went down, there weren’t enough specialist servers in the remaining data centre to keep the system operational.

The cost of over-engineering

When teams are pressured to achieve perfect reliability, they often over-engineer their systems regardless of whether there is a business need. This complexity comes with high operational costs, requiring more staff to maintain. The additional complexity also introduces additional failure modes, ironically making outages more likely. .

Over-optimising reliability can also lead to opportunity cost. Teams may spend months optimising for rare outages when they could instead be building new features, improving user experience, or reducing costs. For example, a government team once spent 6 months developing a process to avoid more than 5 seconds of downtime during a database migration. The money spent on this could have been used for more impactful work elsewhere, or at a more fundamental level could have been spent elsewhere such as hiring additional nurses for the NHS.

The security risks of avoiding updates

As services mature, they generally become more reliable. Bugs that cause early issues are fixed over time. However, as services mature the biggest risk to service reliability becomes changes to the system. Teams aiming for an unobtainable 100% uptime may consciously avoid making necessary updates or implement overly elaborate change management processes. This can be dangerous.

Many modern web services rely on dozens, even hundreds, of third-party libraries – each one a potential source of security vulnerabilities. These need regular updates, but teams often fear making changes that could cause downtime. The result? Outdated services with a plethora of small vulnerabilities that build up over time. If these vulnerabilities align known as swiss cheese vulnerabilities, the risk of a security breach becomes more severe. Furthermore, services that avoid updates can become less relevant to users as they fail to meet their evolving needs.

Frequent releases are essential for maintaining secure and relevant services. Teams familiar with continuous integration (CI) and continuous deployment (CD) often release updates tens of times daily. But when changes become rare, the skills and knowledge of how to do this safely fades, increasing the risk of failure and making teams even more hesitant to make updates.

Planning for the inevitable downtime

The perception that a service needs to achieve 100% availability prevents teams from preparing for planned downtime. Many services don’t have a ‘shutter’ mechanism to notify users when a service is intentionally offline for maintenance. For example  during  a database migration. Providing users with a simple, branded message would offer a much better experience than a generic 4xx or 5xx error page if they try to access a service during downtime.

Government digital services are expensive, but the convenience they offer the citizen generally justifies the cost. However, teams often lose sight of just how much they’re spending. A useful approach is to frame costs in relatable terms, like how many nurses could be employed with that money. When you look at it this way, striving for “.999%” availability is almost  never worth the price.

How can the government move the needle?

UK government services must pass through a series of service assessments during their development stages – discovery, alpha, beta and live. However, many services remain in beta indefinitely. This isn’t because they’re unfit for live deployment, but because teams fear that funding might be cut once they move to the live stage. If these services were built to meet realistic SLAs, they could be operated at a fraction of the current cost.

The Government Digital Service (GDS) standard includes the principle ‘operate a reliable service’. This states that ‘Users expect to be able to use online services 24 hours a day, 365 days a year.’ However, this phrasing unintentionally sets the expectation of 100% uptime, which is unrealistic. Teams are set up to fail if they aim for this, as most government services simply don’t have the budget to support such reliability.

Instead, the service standard should say: ‘operate a service as reliable as necessary to meet user needs.’ It could include benchmarks like:

Matching service expectations to needs

However, it’s crucial to stress that the juice has to be worth the squeeze. Aiming for additional ‘9s’ in availability should only be pursued when the societal cost of not achieving that reliability outweighs the investment required. For example, if the cost of 0.001% of tax returns being filed late is less than guaranteeing 99.999% uptime, then we should avoid spending more money for such small improvements.

Big players like Amazon or Google have modelled what a 15 minute outage will cost them in lost revenue. The web is filled with advice for attaining near perfect availability based on the models of these tech giants. However, the cost of a short outage to a government service is usually inconvenience or at worst reputational damage.. 

In my opinion, most government services could tolerate up to 15 minutes of downtime per day without significant consequences. Of course some services are critical – lives may depend on them. But these are the exception, not the rule. The truth is that most government services still have paper, or phone based alternatives, so our yard stick for online service reliability should be grounded in reality, not in comparison to private sector giants like YouTube or Facebook.

Graceful degradation

Richard Pope’s Platformland shares a vision of 100s of interconnected services lowering barriers to the UK public and enabling a model where the public is served proactively. However, I fear that this interconnectivity will demand even more unattainable  reliability. Instead of  pragmatic thinking about how services should fail. The current model for failure is that an error is raised and a Site Reliability Engineer (SRE) is alerted. However, this rarely results in the original user need being fulfilled. Instead the offending code will be fixed and the user will be forced to use an alternative means of realising their intent.

Embracing SLAs

By following some of the tips in this blog, I believe reliability and user satisfaction can be significantly improved. Healthy discussions about the appropriate level of reliability for services will lead to reductions in costs and waste. Ultimately, a positive approach to SLAs will enhance services and better meet the needs of the British public.

The post Why public sector digital can’t afford to shy away from SLAs appeared first on Made Tech.

In this context, digital transformation isn’t optional. It’s one of the few levers left for the government to reduce costs and improve public services. 

Despite spending over £26 billion annually on digital and technology, the public sector often isn’t seeing the benefits. That’s not because of a lack of ambition or effort. Instead, it’s because too many projects are short-term and focused on launching something new, rather than fixing the full end-to-end service.

To change that, we need a different kind of delivery. One that puts reusability, measurable outcomes and long-term sustainability at the top of the list.

6 steps to reduce spend through smarter delivery

Delivering digital services in government is about more than writing code or launching new platforms. It’s about building services that are more cost-effective to run and better for the people who use them. The key is taking a smarter, more sustainable approach to delivery.

These are 6 things I’ve seen work in practice:

1. Focus on delivery outcomes, not time spent. It’s easy to fall into measuring delivery by headcount or time spent. But what really matters is what’s improved. Has the service become easier to use? Has it saved money or time? Focus on outcomes and your teams will make better decisions throughout the process.
2. Prioritise value through iteration. Don’t hold off for the perfect release. Instead, work incrementally. By getting changes live quickly, your teams will spot what works and avoid wasting time on features nobody needs. It also helps build trust and ensures funding follows what’s proven.
3. Save money through reuse. Many government services share the same building blocks – case management, eligibility checks, identity verification and more. If you can identify these common patterns and build reusable components, you’ll avoid duplication and speed up your next delivery.
4. Match your delivery approach to the risk. Not all deliveries should follow the same path. Some projects benefit from structured upfront discovery work to reduce risk and uncertainty. In contrast, others might need rapid prototyping or quick experimentation. For lower-risk deliveries, I recommend using a ‘build-measure-learn’ approach that can help test assumptions and make more informed decisions. Tailoring your approach to the level of risk helps reduce waste and get better results for your spend. 
5. Think long-term from the start. Cutting corners to save money today will mean that you’re likely to spend more later. Keeping architecture simple and code clean makes services easier to maintain and cheaper to run – something I always push for on client teams.
6. Build internal capability. Long-term savings come from your own teams being able to own, run and improve their services over time. Make sure your suppliers prioritise knowledge transfer and provide clear documentation. This builds confidence and reduces reliance on external suppliers.

For more ideas on how to cut delivery costs read my previous blog Digital: delivering more for less.

How digital delivery can drive better outcomes and savings

Ultimately, government borrowing won’t be solved by one department or a single initiative. But we can make a dent in it. From changes to tax and spending, to saving money in day-to-day operations and using data more effectively. When services are simpler and easier to run – they cost less and work better for the people who use them.

Smarter digital delivery on its own won’t fix the budget gap, but it can make a real difference by:

These aren’t just theories. I’ve seen these approaches work first-hand in departments across government – making services more efficient and easier to use.

At Made Tech, we help government teams design and run digital services that are more cost-effective and better for users – all through lean agile delivery and a focus on building lasting capability. To learn more or speak to our team, visit our delivery services page or get in touch.

The post High borrowing means government needs smarter digital delivery appeared first on Made Tech.

Q: Hi Sade, can you tell us about your career journey into delivery management?

I spent 8 years in the digital field as a software engineer. But if I’m honest, I realised I wasn’t really a code person, it wasn’t my forte. It wasn’t my flow, but I knew I didn’t want to lose my digital edge and the software skills I’d learned. 

I wanted to go into another profession and take advantage of the technical knowledge I already had. That led me to project management starting with PRINCE2, and about 13 years ago I discovered Agile. 

That kind of role really resonated with my strengths in collaboration, communication and delivery. Over time, this naturally evolved into a delivery manager role, where I now get to bring together both my technical background and people skills to lead high-performing teams and deliver meaningful outcomes.

Q: Did you face any challenges during your career transition?

Yes, definitely. One of the biggest challenges during my transition was shifting from a detailed technical mindset to a broader strategic perspective.

As a software engineer, my focus was very much on the specifics – getting the code to function as intended and understanding the finer details of the technology. But as I moved into delivery management, my role became much more about the bigger picture.

I had to start thinking in terms of timelines, budgets, team dynamics, stakeholder expectations and overall project outcomes. It wasn’t just about the code anymore – it was about how all the moving parts came together. 

In many ways, the delivery manager becomes the hub of the project, keeping everything aligned and flowing smoothly. That shift in mindset took some adjustment, but over time it became a space where I could really thrive.

Q: Earlier you mentioned Agile, what is it about that methodology that really resonates with you?

I find Agile to be extremely effective in my role, particularly because it’s built around people. It provides a framework that fosters respect, trust and autonomy, enabling individuals to do their best work within the programme’s boundaries.

However, it’s crucial to avoid what I refer to as ‘mechanical Agile’- where teams simply go through the motions of ceremonies without genuinely engaging. This approach misses the core value of Agile. 

The true power of this methodology lies in focusing on the human side of delivery – creating space for open communication, actively listening to the team and making sure everyone feels heard and valued. When done right, Agile cultivates a culture of empowerment, which in turn drives real progress.

Ultimately, this approach makes delivering value to the customer much smoother and more impactful.

Q: The people side of delivery management – that’s something you’re really passionate about?

Absolutely, it’s one of the main things that drew me to delivery management. Looking back, I’ve always gravitated toward people-focused roles. My degree was in guidance and counselling and when I first moved to the UK I spent a couple of years working with homeless communities. That experience grounded me in the value of empathy, listening and supporting others – skills that have continued to shape my career. 

Since joining Made Tech, I’ve worked closely with the NHS, which has been incredibly meaningful. The NHS touches all of us, so being part of projects that have a real impact on people’s lives is deeply motivating. You can see the benefits not just in theory, but you know it’s going to touch you, your family, your friends and everyone else. So you want to put your best in it. You are, in effect, the end user. 

Q: How do you think your technical background helps in delivery, particularly when it comes to managing and working with many types of people?

Even though I’ve moved away from actively writing code, my background as a developer is still incredibly valuable. It gives me a solid understanding of the technical landscape, which means I can have more meaningful conversations with development teams. 

For example, something as simple as understanding what a table looks like in a database helps me grasp the context of what teams are working on and ask the right questions. Having been on the delivery side myself, I can better appreciate the complexities and trade-offs developers face and that helps build trust and alignment across the team. 

My technical background also plays a key role when working with non-technical stakeholders. It helps me bridge the gap between the technical team and the business side, translating complex concepts into language that’s clear and accessible. 

Q: Let’s discuss leading teams, what does that look like to you?

For me, leading teams as a delivery manager means being the central point of clarity. You’re right at the heart of things, helping the team stay aligned on what needs to be done, when and why. I believe that once a team truly understands the vision and their role in achieving it, that’s half the battle won. People naturally want to do good work, they just need the right direction and context.

Leadership is also about creating the right environment for the team to thrive. I’m passionate about building high-performing teams and that starts with trust, empowerment and clear communication. 

One of the core principles of Agile is to create space for people to be their best selves, and I really take that to heart. It’s not just about managing tasks, but also helping people see their impact, feel a sense of ownership and be part of something meaningful. That’s when teams really come to life.

Q: What else have you learned about building good work relationships?

One of the biggest lessons I’ve learned is that people don’t come to work intending to be difficult. When challenges arise in working relationships, my instinct is always to pause and try to understand what’s really going on. Often, when you step back, you realise there’s a reason behind someone’s behaviour – maybe they’re unclear on what’s expected, or they’re unfamiliar with the Agile process and finding it overwhelming.

That’s taught me the importance of seeking to understand before seeking to be understood. Building strong relationships is about active listening, empathy and trying to see things from the other person’s perspective. 

As delivery managers, we have to work with people, not against them. The moment it becomes adversarial, everything gets harder. But when you build trust and connection, even tough conversations become easier and more constructive.

Are you looking to work with passionate people like Sade? Or perhaps you’re looking to make a similar move from engineering into delivery? Good news, we’re hiring. 

The post Decoding delivery and leading tech teams  appeared first on Made Tech.

This post won’t dive into the policy or the domain itself. Instead, it’s a reflection on how we’ve kept going when things got bumpy. It’s about working in uncertainty, under pressure, with shifting policy, heavy content and stretched teams. It’s about what we’ve learned and what we’re still learning as we try to move a complex service forward.

5 beta challenges we’ve been facing

We’ve been through discovery and alpha. Now we’re in beta, working toward a pilot in the summer and a private beta release later in the year. There’s still a long way to go, but this felt like a good time to pause, reflect and share 5 challenges we’ve faced and how we’ve tried to solve them.

1. When roles get too wide, bring in support

Large beta teams bring scale, but also complexity. On this project, our user-centred design (UCD) team (interaction, service and content designers, user researcher and business analyst) were being pulled in too many directions.

They weren’t just designing. They were refining tickets, managing backlogs, engaging with policy and devs and trying to hold the whole thing together. It was unsustainable.

Our solution to help this strain was by supporting the introduction of a client-side product manager. This was someone that could own the backlog, shape sprint goals and bring clearer focus to planning and delivery.

This one shift has already helped ease the load and rebalance the team.

2. Find your rhythm by creating space for work that matters

Naturally over time, what started as a few useful meetings turned into a packed calendar – ceremonies, stand ups, working groups and huddles.

Nothing was done ‘wrong’, this kind of thing happens as projects evolve. As the service took shape and the team grew, our ways of working expanded to keep pace. But without noticing, the balance shifted. There were so many sessions that people struggled to find the time for the deep, focused work needed to make real progress.

We stepped back and took stock. A retro helped us understand which meetings added value, and which didn’t. From there we started streamlining. Fewer meetings, more targeted attendee lists, clearer purpose and more room to think.

3. Policy and legislation keep changing, so learn to work with it

On this project the policy is still progressing through Parliament and all of the secondary legislation is yet to be finalised. That means we’ve had to deal with changing requirements, new priorities and some rework. 

Rather than let this derail the team, we mapped the service and clearly marked areas where policy is still undefined. To help manage change, we introduced content and design logs to track what’s changed and why. We talked openly about ambiguity and worked to build team resilience around it. 

In a beta like this, some uncertainty is the norm, not the exception. We encouraged the team to focus on what’s known and move forward with confidence, while flagging assumptions, documenting decisions, and staying ready to pivot. That mindset has helped us keep moving while also contributing to shaping policy in a user-centred way, even when things are in flux.

4. Heavy content lifting: our approach to a demanding workload

This is a content-heavy service with complex, multi-page guidance that needs to be shown clearly and simply in the user journey. As policy and legislation evolve, content often needs reworking. Some become outdated and new features introduce fresh guidance needs.

Managing that volume with a single content designer has been tough, especially with shifting priorities and ongoing context switching. To help ease the pressure, we mapped what content is left to do, what was blocked and where the biggest risks were.

This helped create clarity around the remaining work, making it easier to plan, prioritise and move forward in a more achievable way. It also gave us better visibility of where we might need to adapt or bring in additional content support to meet the demands of the beta.

5. Early UCD work matters and we’re making it visible

As soon as features start being built, it’s easy for the earlier UCD work (research, mapping and prototyping) to fade into the background. But that groundwork is critical to building the right thing, not just building anything.

We’ve made a conscious effort to recognise and celebrate that work – including in blogs like this one. It’s not just about morale, it’s about making sure every part of the team sees the value of what’s come before and how it connects to what’s happening now.

Good delivery is always a team effort, and it starts long before the first line of code. Keeping that work visible helps everyone stay aligned on the purpose behind what we’re building.

The beta benefits – we’re always learning

Betas are hard, and we’re still building, learning and adjusting.

We haven’t figured everything out, but we’re moving forward, because we’re open about what’s not working, supportive when people are under pressure and pragmatic about what we can fix now versus what needs to come next.

Every beta is different. This is just what we’ve learned from ours so far. Hopefully, it helps others facing similar challenges.

Looking to read more on what our user-centred design team are up to? Take a look at their latest blog posts, covering everything from career journeys to design insights. 

The post Beta blockers: 5 challenges and how we navigated them appeared first on Made Tech.

Q: What were your first roles in tech and how did they shape your career?

I began in a traditional technology consultancy, where I spent a year coding in Oracle/SQL which provided a strong technical foundation. From there, I moved into business analysis, project management and eventually programme management.

Along the way I worked as a product specialist for Siebel, a CRM tool that predated Salesforce. I was in their fast moving consumer goods team. During this time I spent my 20’s flying around the world looking after projects.

I came back to the UK as I was at a stage in my life where I wanted to get married and start a family. So I joined a consultancy and had projects in the UK which were great. 

While I was on maternity leave, Vodafone bought that consultancy I was with because of our expertise in mobile device applications. I spent 14 years under Vodafone doing various different roles. One of which was helping out on their seal implementation. We worked with Accenture on that. It was the biggest programme for them in Europe at the time.

I left to join the civil service and moved into public sector leadership at the Department for Transport (DfT). After that I did a bit of time at Deloitte, and now here I am at Made Tech.

Q: What made you want to make the shift back to working with government departments full time?

Although I had worked alongside the Big 4 for much of my early career, I had never actually worked for one. So, I was thrilled to receive a job offer from Deloitte. While there I spent 18 months at the Home Office on a project to replace one of the legacy applications within the Future Borders portfolio – which was really interesting. 

I was leading a large blended team of Deloitte people, other consultancies and civil servants. It was challenging but also fun and exciting, and I really enjoyed it. I then decided to dedicate myself to full-time public sector delivery. I was really pleased to join Made Tech where it’s our sole focus. The passion for public sector and delivery expertise in our Made Tech teams has made my first few months really enjoyable. Long may it continue!

Q: Thinking about your work with the public sector, which project had one of the biggest impacts?

One of my favourite projects was when I worked at Vodafone. We rolled out mobile devices to adult and children’s social care in Nottinghamshire County Council. 

The reason I really loved it is because a lot of the people in that role are women with families. They previously worked on fixed office computers with specific deadlines. Many would be out for an assessment on a child or adult and have to race back to the office to write it up within 48 hours or 24 hours – depending on the severity. 

By empowering women with mobile technology they could choose when to do their writeup. They had the option to go home and pick their kids up from after school care for example. Being able to give all parents, but predominantly women, the flexibility to work like that was really positive and made a huge difference to their lives. I’m proud of that one. 

Q: Let’s talk about your time at the Department for Transport building their digital services team

I joined the newly established digital services team at DfT. I spent 5 years focused on creating the team, setting up project management and digital delivery.

It was a really interesting and challenging thing to do, especially coming into the civil service. It was a significant shift from the private sector. I quickly realised how different government operations were, especially concerning budgets and the annual spending cycle.

Q: That’s a lot of adaptability, what are some of the biggest challenges you’ve faced?

Project delivery is hard. Digital delivery is a really tough thing to get right and it often goes wrong. You can automate parts of it but ultimately it’s a set of people with a desire to get the thing done. 

I’ve seen a lot of projects that have stalled over the years across different technologies and sectors for different reasons. It can be really heartbreaking when you’ve worked on something for a long time to not see it actually go live.

However, staying positive – I think that compared to when I first started my career, delivery progress is much quicker and services go live much more frequently now. That’s the benefit of using agile methodology.  Focusing on delivering the features that have the greatest value first, taking regular feedback and rapid iterations have all helped improve digital delivery.

Q: How do you get through those challenging moments?

I’ve spent a long time in this career, and I’m at my best when I’m challenged, pushed out of my comfort zone and learning new things—that’s when I’m most excited. I’m best when I’m on a learning curve.

Some advice for those moments? Just say yes and figure it out later. While that may not work every time, I often try to have that in my mind. When someone asks you to step outside your comfort zone, adopting a ‘just say yes’ mindset helps you figure it out along the way.

Q: Finally, what made Made Tech stand out as your next step?

The thing that attracted me to this role was the split between delivery and growth. I joined because the role lets me support delivery, lead delivery teams and contribute to the organisation’s growth.

The growth trajectory we’re on at Made Tech really motivates me. I’m excited by the opportunity to work in digital delivery and specialise in the public sector, watching it grow and mature.

If you’re also motivated by the idea of creating change in the public sector, take a look at our open roles. 

The post Creating change in public sector delivery appeared first on Made Tech.

Gregor Hohpe’s “Architect Elevator” concept offers a solution. It positions technical architects as the crucial link between strategic vision and technical execution, ensuring alignment at all levels. Architects, like elevators, move seamlessly between high level business goals and down into the technical details, translating vision into action and driving outcomes.

Discovering what makes a true ‘agent of change’

To better understand how technical architects can be true ‘agents of change’, we launched a Discovery. We analysed 30 public sector projects using surveys, Q&A’s, and interviews with lead engineers, delivery managers and architects. The Discovery showed distinct patterns of success and failure, highlighting the influence of architects on project outcomes.

One thing was clear: on projects where architects and development teams weren’t aligned, organisations often strayed from their original objectives, quality dropped and technical decision-making was a struggle.

One research participant spoke about a project where the client’s key goal was to replace a costly legacy system. But with little architect involvement, the team lost focus and direction, building useful new features, but ones that didn’t support the main objective. The result? They ended up maintaining two systems – doubling the cost and the workload without achieving the desired outcome of being able to migrate from the old system. 

Several participants in the research said that whilst client technical leaders have a lot of business domain knowledge and context, many aren’t up to speed with the latest technologies and practices. To keep up, they rely on major technology vendors for advice but don’t keep their engineering teams in the loop. Our Discovery revealed that this led to solutions that frustrated the engineers, making them wonder why they were doing something. Many had doubts about the design but still had to deliver it. In one case, an important technology decision failed, which caused the engineers to lose respect for the technical leaders. This led to a growing chasm between the two groups, and the engineers started implementing solutions without oversight, delivering at pace but ultimately causing problems for the business.

Skills and behaviours of effective technical architects

Our discovery project uncovered some interesting insights about what makes software architects truly effective. We identified 49 key skills and behaviours, then distilled these into eight core competencies. These range from hard skills like resilience and problem-solving to softer abilities such as active listening, influencing, and stakeholder management. The best architects serve as bridges between business and technology. They’re able to explain complex technical concepts to non-tech folks and translate business needs into technical requirements. Only when they become strategic communicators and make the most of this diverse toolkit of skills, do they become true agents of change who lead projects to successful outcomes. 

What we learned and applied

To ensure we’re adding value for clients, we’ve developed tools based on our research findings:

Technical architecture skills maturity assessment

Off the back of our Discovery, we created an interactive tool to help organisations assess their existing teams. This tool allows teams to self-assess and uncover gaps in their skillset, whether it’s technical resilience or business leadership. It’s a fantastic resource for organisations to use internally, helping them build more balanced, capable architecture teams.

Using the tool, one client identified that they had a large number of individuals who excelled in technical areas like integration and cloud software but struggled with stakeholder management and strategic alignment. It helped surface these gaps and provided actionable insights on how to address them.

Architecture playbook

We’ve also developed a playbook that captures the best practices of architecture, with a focus on lean and efficient outcomes. Our six-phase approach guides organisations from understanding their current state to delivering successful digital transformation:

1. Finding your bearings – Aligning business goals with technical direction.
2. Verifying the destination – Ensuring clarity and agreement on objectives.
3. Shaping the team – Assembling the right mix of skills and behaviours.
4. Squad checks – Structuring the delivery team for success.
5. Plotting course options – Offering alternative paths to the goal.
6. Navigating the journey – Supporting teams to deliver on time and within budget.

By creating a replicable playbook, we’re able to drive faster, more cost-effective outcomes consistently. 

Want to see what it’s all about?

Using the learnings from our Discovery and applying our wider thought leadership has helped clients like the Home Office and the Ministry of Justice refine their technical teams, leading to better and more successful project outcomes.

By identifying gaps in technical leadership, we’ve helped organisations understand why past digital initiatives may have failed or stalled. Our tools highlight key warning signs, giving organisations the insight to course-correct early and avoid common pitfalls. If you’d like to try out our playbooks or behaviour assessments, please reach out for a chat.

The post Technical architects: Agents of change appeared first on Made Tech.

In this blog, I explore the role of technical architecture in driving outcomes. I’ll cover the tools and approaches that’ll help ensure success. Things such as defining the non-negotiables, collaborating with stakeholders, communicating clearly, and managing risks. 

Establish the non-negotiables

The first step in establishing a technical architecture approach that drives the right outcomes is to set a north star. When push comes to shove and difficult priority calls need to be made, what is your single most important non-negotiable? This could be a particular technology choice, a cost saving that needs to be made, or the team shape available. Whatever it is, identify it and accept that all other decision points exist to support that goal. 

It’s important to listen to what users and the experts within your organisation are saying. That said, different stakeholders will likely have different priorities, so non-negotiables may differ depending on who you ask. So as a technical architect, the ability to communicate, build rapport, influence and advise, are all skills I keep sharp in my tool box. Have the conversations – lots of them. Find common ground, bring people on the journey with you and get buy-in. Once you’ve identified what your non-negotiables are, you’ll be able to have meaningful conversations about where to compromise, and what hard constraints you’ll have to navigate. 

Get agreement on key architecture qualities

One effective way to reach a consensus on architecture quality is through collaboration. Here’s a straightforward approach that I’ve found works.

1. Gather stakeholders: Bring together key representatives from each stakeholder group for a whiteboard session.
2. List architecture qualities: Write a list of architecture qualities.
3. Rank priorities: Have each stakeholder list their top 5 most important qualities in order of priority. Let them share their unique perspectives with the group.
4. Assign points: Assign points based on priority (e.g., 5 points for priority 1, 1 point for priority 5). You might need more granular scoring but it’s the discussions that follow that matter most.
5. Discuss and agree: Count up the votes, discuss the outcome, and agree on the top 5-7 most important qualities as a group.

I’ve found that this collaborative exercise builds empathy among stakeholders and surfaces important qualities. It reveals a potentially long list of qualities that, as a group, no one is overly concerned about, as well as insights into what has mattered historically and what may become more important in the future. 

Communicate your technical architecture

Technical communication done well enables digital and non digital teams/stakeholders to understand if an architecture is driving the right outcomes. 

My rule of thumb is that if you need to provide in-depth explanations or detailed walk-throughs to make your diagrams make sense, they’re probably not as effective as you thought. I recommend modelling your architecture in code to help you to describe it accurately and concisely, it will also ensure consistency and promote reuse. 

The C4 Model with Structurizr is my go-to practice and tool of choice. It helps present the relevant parts of your architecture, at the right level of abstraction based on your audience. That makes it ideal for communicating your technical architecture effectively, and it’s extremely powerful when it comes to helping you diagnose issues in a collaborative way. Like all diagram techniques, it does take some practice. Using the C4 Model diagrams requires discipline. I’d urge you to focus on what exactly you’re trying to achieve with it and always think about your audience. It’s not about documenting everything in a diagram, it’s about building a shared understanding.

What’s great about using Structurizr is that the constraints imposed by the domain-specific language (DSL) help you rationalise and describe the architecture of each system in a consistent way. Once you have a model of your architecture, it then takes minutes to create clear and concise visualisations.

Assess performance

The next step is to view your architecture from the perspective of a particular quality goal or outcome that you feel your architecture is struggling to meet. 

On many projects I work on, we uncover and reveal key issues that stop an organisation from achieving their desired outcomes, simply by using system context diagrams. These diagrams are crucial because they are digestible by both technical and non-technical stakeholders. 

Working with one particular government organisation, we brought together leaders from across various departments and ran a risk storming exercise on their entire technical estate. What we learned changed how we viewed their architecture, brought to light how the current set-up was impacting their goals, and helped us focus on the most critical issues for the organisation from that point on.

We also gained valuable insights into their specific quality goals, such as system resilience. We produced detailed system container diagrams for different engineering teams within a complex technical environment. This enabled us to run a collaborative risk storming session with all squads simultaneously, with prompts to focus their thinking towards reliability engineering concepts. This highlighted clear high risk areas which we explored together to help them decide where to focus their mitigation efforts and identify which were low risks they could tolerate.

Regular risk storming is my preferred method for evaluating how a system’s architecture is performing, whether looking at the most important qualities or specific outcomes. They’re also useful for sprint retrospectives, post-mortems, or rebuilding stakeholder trust. The key is to keep assessing and addressing your biggest risks.

However, running these sessions can be challenging. I recommend careful planning, active stakeholder engagement, clear prompts for the attendees, and creating a safe environment for discussion.

Standing on the shoulders of giants

Crafting an effective technical architecture can be challenging and daunting, given the sheer number of options available and the need to meet user and organisational needs. The list of giants that have elevated our understanding of what software is, and what it can do, is a long one. I won’t attempt to list them all here, but the following are the main ones that influence the way I work with clients. 

• Mark Richards, Neil Ford, Pramod Sadalage & Zhamak Dehghani for giving us the books “Fundamentals of Software Architecture: An Engineering Approach” and the sequel “Software Architecture: The Hard Parts”. These provide the foundation for understanding the essential practices of modern software architecture and how to perform effective trade-off analysis across distributed systems.  

• Murat Erder and Pierre Pureur for giving us the book “Continuous Architecture In Practice” which takes a principled approach and focuses on how to continuously deliver an evolving architecture that drives quality. 

• Simon Brown’s C4 Model and collaborative risk identification technique risk-storming. As described within this blog, I’ve found this instrumental in my day-to-day work.

By standing on the shoulders of these giants (and the many others), we can see further. We are armed with a wealth of knowledge that helps us build architectures that truly drive the right outcomes for end users and citizens. I encourage you to draw on these resources, blend them with your own experiences, and continually adapt as your organisation evolves.

What I’ve shared here comes from my own experiences and the valuable insights from others in the field. As you use these strategies, know that they’re part of a bigger picture of knowledge, practice and completely yours to make your own.

The post Is your technical architecture driving the right outcomes? appeared first on Made Tech.

Created in conjunction with other attendees from local authorities across the UK, the Co-Production Framework outlines ten core principles designed to ensure that new software and technologies are built collaboratively, not just by senior stakeholders but with direct input from those using these tools. 

Here’s a closer look at these 10 principles and why they matter.

Contents

1. Prioritise engagement
2. Take an outcome-focused approach
3. Be led by the community
4. Be inclusive
5. Diversify mechanisms for engagement
6. Incentivise participation
7. Engage your community
8. Create confidence
9. Ensure accessibility and usability
10. Comply with governance

1. Prioritise engagement

Given resource constraints, it’s essential to prioritise engagement efforts strategically. Establishing clear principles helps manage resources effectively while maintaining transparency and responsiveness to community feedback.

We identified that different local authorities have different budgets for community engagement and testing – which is why understanding the budget and options available to you at an early stage is so important. 

That budget should cover everything from your interviews and testing to followups such as:

• 1-2-1 interviews
• Test and focus groups
• Incentives and rewards for participants’ time
• Build updates
• Outcomes and insights from interviews
• Actions and timelines 
• Arranging for follow up feedback sessions

All of these options may not be possible, so it’s important to evaluate the affordable options available to you that will give you access to the data you need before, during and after development.

Actions:

• Establish principles for prioritising engagement efforts
• Collect and respond to feedback promptly
• Communicate actions taken based on community input

2. Take an outcome-focused approach

Focusing on the value and outcomes of engagement rather than just the solution itself ensures that the technology developed addresses real community needs. Outcomes should be tied to specific user groups and should kick off the ‘how’ part of our planning stage to ensure you are engaging and testing the product with the right people.

Actions:

• Define clear, value-based outcomes for the project.
• Engage community members to provide expertise and insights.
• Let engagement focus on the benefits and impact of the solution.

3. Be led by the community

Decisions should be guided by the needs and preferences of the community. By co-developing solutions through interviews, mapping, and journey ideation, local governments can ensure that the final product is closely aligned with what users want and need.

Actions:

• Identify needs expressed by community members.
• Ensure continuous community involvement throughout the project.
• Use co-development activities like interviews and mapping.

4. Be inclusive

Inclusive outreach is the foundation of effective co-production. By actively engaging with underrepresented groups, local governments can ensure that diverse perspectives are included in the development process. This not only enhances the relevance of the technology, by ensuring that it delivers on its promise and is accessible and usable by its end users, but also builds broader community support.

We suggested that local authorities look to:

• Community groups hosted at local centres and churches
• Advertising for respondents in supermarkets, local convenience stores, on buses and through flyering

Actions:

• Identify and reach out to underrepresented groups.
• Schedule community events to engage these groups.
• Utilise local venues and events to foster diverse participation.

5. Diversify mechanisms for engagement

Using a variety of engagement methods ensures that everyone has the opportunity to participate in a way that suits them best. It’s also key to ensuring that all voices are heard, not just those that speak the loudest or are actively involved in the community as this can affect how products are built. Inclusivity is crucial for gathering comprehensive feedback and ensuring what’s developed is user-friendly and accessible to everyone.

Actions:

• Schedule one-on-one interactions and virtual sessions.
• Organise community meet-ups and distribute surveys.
• Develop user-friendly apps for continuous engagement.

6. Incentivise participation

Offering incentives is an effective strategy to encourage participation, especially from those who might not typically engage. Financial rewards, vouchers, and training opportunities can motivate broader involvement and enrich the development process with varied insights. The incentive you are able to provide will largely depend on the budget and resources available to you as part of this project.

Actions:

• Design incentive programs including monetary rewards or vouchers.
• Offer training sessions to boost participation.
• Explore additional strategies to motivate community involvement.

7. Engage your community

Forming dedicated community engagement groups or reaching out to individuals with strong views can provide deep insights into the needs and expectations of the community. 

We spoke at length about the difficulties in striking a balance between underrepresented and vocal community members can be hard. Often more active community members will have oversight of the opinions and challenges of those within their community – and can provide insight into different cases. However, even when the voice of one may represent the voice of many, it’s important to challenge the ideas expressed and validate supporting and opposing opinions to overcome interviewer and interviewee bias.

Actions:

• Engage individuals with strong community views
• Use practitioners to gather insights from their networks
• Document and integrate feedback from these engagements

8. Create confidence

To overcome the issue of bias and the availability of participants from all groups, we look to foundational principles around credible sampling in order to create confidence in the hypotheses and actions within a project. This could be a whole framework in itself so we suggest taking a look at these frameworks and methodologies:

• Delphi method: Researchers can use this method to gather data from a diverse group of participants through multiple rounds of questioning, ensuring that all voices are heard and considered.
•  Nominal Group Technique (NGT): In interviews or focus groups, NGT can help ensure that all participants have an equal opportunity to share their views, minimising the influence of dominant voices.
• Thematic analysis: Researchers systematically code the data and develop themes that reflect the perspectives of all participants, not just the most vocal ones.
• Silent brainstorming: Ensures all participants have an equal opportunity to contribute their thoughts without being influenced by more dominant voices.

And many more. Use this prompt in ChatGPT for a list of other methods: What frameworks or studies are out there to help researchers ensure that they draw insights and actions from all interviewees, not just the majority of those that speak the loudest in group and one-to-one interviews

Actions:

• Develop criteria for selecting a credible sample of participants
• Regularly evaluate the quality of representation and feedback
• Address any gaps in participation or feedback promptly

9. Ensure accessibility and usability

Ensuring that solutions are accessible and usable for all participants is essential. Regular reviews and adjustments based on user feedback help maintain high standards of accessibility and usability, making the technology more inclusive.

Actions:

• Evaluate the accessibility of tools and platforms regularly.
• Implement feedback to improve usability.
• Continuously adjust tools and platforms based on user input.

10. Comply with governance

Addressing governance, data protection, and security is critical for enabling meaningful participation. Incorporating ongoing feedback into governance frameworks ensures the project remains compliant and trustworthy.

Actions:

• Ensure compliance with data protection regulations.
• Conduct Data Protection Impact Assessments (DPIAs).
• Integrate ongoing feedback into governance structures.

Conclusion

Adopting a co-production framework is not about ticking boxes. Instead, it is about fostering genuine collaboration with the community. This approach helps save money by identifying potential issues early, supports seamless delivery by aligning with user needs, and garners robust support from residents and end-users. Testing the concept and product before, during, and after development ensures that the final technology is effective and embraced by the community it serves. By following these principles, local governments can develop AI and emerging tech solutions that make a difference.

Special thanks to Datnexa and Outcomes Matter for hosting LGAi Unconference.

The post Build better products: A Co-Production Framework for AI and emerging tech appeared first on Made Tech.