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.

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.

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.

Navigating my career and dyslexia 

I was diagnosed with Dyslexia at age 21 during my second year of university, back when I was studying Tourism Management. I had an interesting career from then on. I first dabbled in events. Starting my own company during my studies, then joining an events and wedding company. Facing 3 years in that role with no progression I needed a change. I was dared by my late cousin, Peter Cheung (who later became my mentor) to move to Singapore and start again. So that’s what I did. 

If one thing you needed to do in life was to get a job, how would you do it? Cousin Pete

Cousin Pete shared his wise words of advice to “get on with it”, and if all else failed I knew I could return home. During interviews abroad I would mention my Dyslexia, but found this often put my application straight into the ‘do not hire’ pile. I felt discouraged. 

I eventually landed an events role with the St Regis Hotel. I continued pushing and started to build my career, working for different luxury hotels and travelling across Asia. But something was missing. Through my connections I was offered an interview for a Business Development Manager role (which I had no experience in) but was recommended for. I thought, why not?

I got a call offering me the job just as I was about to board a flight back to the UK. It turned into a flying visit home and not long after, I relocated to Singapore. I was a Business Development Manager for 2 years with MCI Group where I learnt the art of storytelling. It wouldn’t be until 2019 when I returned home – with one bike, 3 suitcases and a laptop bag. 

Back in the UK but where to start?

When I was back home I didn’t know where to start. I had just shy of 10 years international experience – shouldn’t that make me more marketable? Following some much needed time with my family I landed a role at American Express GBT. One month in, the pandemic started and I was furloughed. I was frustratingly looking once again for a new role. I knew then I wanted something different, I just wasn’t sure what yet. 

I then joined the British Dyslexia Association (BDA) for one year. My time with BDA made me realise that working somewhere Dyslexic-friendly was really important to me. They had everything in place and the onboarding was seamless. They gave me advice to contact Access to Work – a brilliant government scheme that can help you get or stay in work if you have a physical or mental health condition or disability. I was also given handouts after my meetings detailing what we discussed and next steps. A new one for me, they also pointed me towards physical tools such as yellow tinted acetate paper that can help reduce visual stress. 

BDA supported me not only in the ways you might imagine, but they also helped me realise what I wanted to do in my career. I wanted to help people, not just in the private sector but the public sector too. I wanted to work somewhere that has the support and accessibility in place for anyone with Dyslexia. I knew that at my next company I wanted to create that legacy. 

In September 2022 I joined Diverse and Equal. A tech for good organisation that takes on people with no tech experience and trains them through an intense course. This is where I decided that a delivery manager role would suit my personality and what I needed out of a career – a role where I could help people. 

After completing the course at Diverse and Equal I eventually reached out to Made Tech. Ahead of my interview the People team asked me how they could support the process – as someone with Dyslexia, this was amazing to hear! I received the interview questions beforehand, making the whole process feel truly accessible. I felt like I had a fighting chance. The interview was smooth and friendly and honestly, one I really enjoyed. 

Spoiler – I was offered the role. My line manager and project line manager met with my Dyslexic trainer who then did a workshop that was open to the whole of Made Tech and had some of the great tips I’ve mentioned so far. I’ve been here for over one year now, so I must be doing something right. 

Tools and techniques I use

Making the decision to join Made Tech was a great one for me. With a supportive team I’ve been able to really find my space in tech. So here’s a few nuggets of advice that have been helpful to me along the way.

Firstly, be open about it. It can be scary as the worry of feeling judged is always there. But remember, when looking for a new role, interviews are 2-way. It’s as much about making sure an organisation is right for you, as you are for it. Keeping quiet about your Dyslexia or any other type of personal difficulty might cause you headaches later on. When in reality – they could (and should) support you from day one. 

Once you’re in your new role speak to your team about how they can support you or particular ways of working that really help your Dyslexia. For me that means receiving a point by point summary of all meetings. This way I can make sure I’ve fully understood everything that was discussed. I also find giving myself 30 minutes at the end of the day to plan for tomorrow and having my clothes laid out for the morning super helpful.

Now what would a blog post be without a helpful resource? Here’s a few final tools that might also help you if you have Dyslexia too:

• Otter AI – helps transcribe meetings in real time, record audio and more
• Speechify – this one is great for reading notes back to me
• Grammarly – the name says it all, this tool gives you options on tone of voice and sentences
• a dictaphone recorder is useful when meeting with clients, you can record the sessions and listen back to it later
• yellow tinted acetate paper is great if you find it helpful to print out paper, it helps reduce things like visual stress so you can focus easier (this also works online)
• an hourglass timer, although it may seem a little old-school – when the sand has all gone I take a breather and step away from my computer for a break 

Throughout my varied career and eventually finding my calling as a Delivery Manager, my Dyslexia is something I’ve had to learn to navigate. But one thing has always been clear to me – be honest and upfront. This is how you can make sure you have the right tools, techniques and most importantly, support, in place so you can do your job well. 

If you’d like to hear more insights into navigating career transitions and overcoming obstacles in the tech industry I’ll be at Agile in the City Bristol on 6 November!  

The post Dyslexia, delivery management and me appeared first on Made Tech.

In this blog I’d like to share some personal insights into how the initiation and discovery phases can help you create impactful and valuable digital services that deliver the benefits you set out to achieve at the start. 

So what is a valuable service?

It’s useful to remind ourselves first of all, about what constitutes a valuable service. A valuable service is usually defined as one that delivers a combination of these elements:

• addresses a problem or fulfils a need for users
• aligns with objectives
• delivers economic benefits
• saves time
• streamlines processes
• is accessible for all 

The Government Digital Service’s service standard provides a structured framework for building these valuable digital services and includes discovery, alpha, beta and live stages.  What’s often missed by digital teams is remembering to revisit the drivers that led to the project being funded in the initial business case. Taking the opportunity to revisit the legislative or financial reasons behind a project is crucial to success.

Understanding the value proposition

Crafting a valuable service starts right at the beginning, by looking to understand the core value proposition. It’s about delivering tangible benefits that resonate with both users and stakeholders. That’s why I’m a big advocate of collaborative exercises like the MadLibs workshop. 

Bringing together key stakeholders, we fill in the blanks to articulate why our service matters and the impact it will have. It’s a simple yet powerful way to align everyone towards a shared understanding of our mission and vision. Using this exercise, stakeholders are given prompts such as “Our service helps to _________, so ________.” Each participant fills in the blanks with their perspective, resulting in a collective understanding of the service’s value proposition.

Ultimately, the value proposition should be a one or 2 sentence summation of the key components of the business case, helping the team remain focused on the expected outcomes.

A hands-on approach to identifying users and their needs

But crafting a value proposition is just the beginning. As we move into the discovery phase, it’s all about rolling up our sleeves and diving into user research. We don’t just rely on data or intuition – we go out there and talk to the people who will actually use our service. By understanding their pain points and needs first hand, we can validate that solving the identified user problems would meet the aims of the business case, using tools such as benefits mapping. 

Quantifying outcomes and benefits

And of course, no discovery is complete without defining outcomes and quantifying the predicted benefits. It’s not just about crunching numbers; it’s about taking a holistic perspective. We look beyond the metrics to understand the real impact our service is having on people’s lives. Are we saving them time? Are we making their lives easier? These are the questions that drive us forward and ensure that our future service will make a real difference in the world.

If you are considering building a business case for an AI project within the public sector you can read our full guide here.

A journey of discovery and impact

Navigating the initiation and discovery phases of digital service delivery is more than just following a methodology – it’s a journey. By understanding the pain points first-hand, creating a value proposition, and identifying anticipated outcomes, we can create services that not only meet citizens’ needs but also deliver tangible benefits against the business case. And for me, that’s what it’s all about—using technology to make a real difference in people’s lives.

Watch my recent Digital Leaders webinar to find out more about this topic and the subsequent phases of delivery. In particular there’s a matrix to help you look at cost versus value decisions in a slightly different way.

The post From idea to impact, the crucial steps in digital service delivery appeared first on Made Tech.

In this post I’m going to share what the tech sector as a whole needs to do more of, and that includes us too. I’ll also touch on the steps we’re taking to make planet-centred design a priority. 

Calling the tech sector! We need to do more

When it comes to creating positive change for the planet, we often hear the phrase ‘digital by default’ – on paper it seems to suggest progress and efficiency. But doing things digitally doesn’t necessarily mean doing things sustainably. The sad reality is that our industry needs a wake up call if we want greener services in society to become the norm. 

Last year, UN Secretary General, António Guterres put out a clear call to action at the launch of the Synthesis Report of the intergovernmental panel on climate change. Antonio says that our world needs ‘climate action on all fronts – everything, everywhere, all at once’.

What this means for the tech sector is that we need to build a fuller understanding of the sustainability impact of the products and services we design and deliver. While yes, creating change will require stronger governance and an industry-wide culture change, there are a few questions we can ask ourselves on a much smaller scale to get started, including:

• how might we design for end-of-life when the product or service may no longer be needed? 
• how will the products and services we deliver affect the lives of the citizens? – this can touch on many different things, from changing daily habits to consumption patterns
• does the sustainability impact of this product or service justify its existence?

Asking these questions and acting on the answers at the start of your next project is just a small way we can all start to introduce the idea of sustainable design into our work. While there’s still a long way to go in our sector, for all of us, one thing remains true – if we want to see real sustainable products and services, the tech sector needs to change.

The hidden impact of our carbon emissions

To understand how technology contributes to, or reduces impact on our planet we also need stronger frameworks around measurement. While the UK’s Streamlined Energy and Carbon Reporting (SECR) policy does require organisations to share energy use and carbon emissions information in their annual reports – it doesn’t go far enough.

At the moment, organisations are only obliged to publish greenhouse gas emission reports on ‘direct effects’ and ‘enabling effects’. Not to get too technical, but that means the impact of the technology sector itself and the environmental impact when technology is applied to other sectors. For example, on a typical project this would include the sustainability impact of:

• the organisation and its delivery partners involved in designing and delivering digital services
• the product or service itself

While this is a step in the right direction, we still need more. Within this SECR policy, reporting on what the government defines as ‘Scope 3’ emissions would paint a more interesting picture. Scope 3 emissions are those that are a consequence of your actions, that occur at sources you don’t own or control – currently reporting on these is voluntary. An example of this is travelling for work using transport not owned or controlled by your organisation – catching the train or taking a taxi etc. 

If it was necessary to report on Scope 3 we’d see the systemic effects of technology-driven change. In other words, we’d gain valuable insights on what behavioural change has happened across society due to a new technology, and how these changes affect the planet! 

We’re not only here to be critical – the good news is that small changes are happening. Governments around the world are starting to revise their approach to reporting to highlight the hidden impact within emissions data. Making the publishing of Scope 3 emissions data a legal requirement here in the UK is a crucial step if we want to build a more sustainable future for our citizens.  

Sustainable steps at Made Tech

We don’t have all the answers yet. We’re still at the start of our own journey at Made Tech, but we have taken our first steps. In our own team we’re asking more questions to build our understanding of this problem, some of these include:

• how might we make sure that we’re not just focusing on carbon emissions?
• how does digital both enable and endanger our transition to a sustainable future?
• what might those designing and delivering services already be doing that can help?

There are also some practical activities we’ve started this year:

• put together a planet-centred design working group to lead and coordinate our efforts 
• organised upcoming training for our teams on planet-centred design and designing sustainable services
• started research into what has already been done and where we can can adopt and adapt

Later this year we’ll share more on our commitment to planet-centred design with updates on everything we’ve mentioned so far. We know we still have quite a way to go, but this is a hugely important journey the team are excited to be part of. We can’t wait to share the changes we’re making with you. 

Is planet-centred design something your organisation is thinking of? 

If you’d like to stay up to date with all of our latest blog posts and upcoming events, sign up to our Made Tech Insights newsletter.

The post It’s time to design and deliver greener products and services appeared first on Made Tech.

It was a great session that got me thinking about how I engage my own team. Ruth’s presentation looked at different techniques and activities designed to improve engagement and help create a more comfortable culture. In this post I’m going to take you through a few exercises that help build connections. 

Think of an elephant

I really enjoyed the first exercise which involved asking the group to think of a thing. In this example, Ruth asked us to think of an elephant and a few people were then asked to share their mind’s-eye view of their elephant. Of course, they were all different. 

This is a great way of showing your team that all ideas are different, but valid. I immediately thought it would be a great exercise to kick off a design sprint to get people’s creativity flowing. 

Checking in with your team

Checking in as a team rather than individuals has more value than I initially thought. It’s something I’d usually do one-on-one, but in a group it helps build trust between team members. 

In the workshop we used a technique called the weather scale. This is where you ask people to write in the chat window how they’re feeling using weather-related terms like sunny or cloudy. 

It’s interesting to use, in that you can get a feel for how others are doing in a group setting. That helps you to offer support or space to those that may need it. You could also use a traffic light system with red, green or amber used to reflect how each team member is feeling. Here’s how that could look in practice:

Me: To start our check-in let’s go around the group and share how we’re feeling using the weather scale. Remember, it’s just a general indication of your overall mood or state. Who’d like to go first?

Natasha: I’ll start. I’m feeling sunny today! Everything is going smoothly and I’m excited about the progress we’ve made.

Me: That’s great to hear! Keep up the positive energy. 

Gary: I’m feeling mostly rainy. I had a rough weekend and it’s been affecting my focus and motivation. I could use some help to get back on track.

Me: I appreciate your honesty. We’re here for you, and let’s discuss how we can support you.

The weather scale is a simple way for team members to express their state of mind without getting into personal detail. It allows you as the delivery manager and the rest of the group to understand the team’s emotional wellbeing, identify concerns and provide support where it’s needed.

The spider of possibilities 

This next exercise is a great way to reflect on a situation and brainstorm different solutions and possibilities. For this you need to draw a spider. You then ask questions about your chosen topic, like what’s the worst that could happen or what’s most likely to happen? Use each of the spider’s legs to show a possible outcome.

Finally, ask how you can make each outcome more likely. Knowing that there are different possibilities can be helpful, and it’s useful when it comes to accepting an outcome.

Fast 8s

Fast 8s are an exercise that helps your team brainstorm a lot of ideas quickly. It’s a fast-sketching activity that challenges people to roughly sketch 8 distinct ideas in 8 minutes. It’s important to make clear this is a rough sketching exercise and no one has to have perfect drawings. 

Here’s how it works:

1. Give everyone 8 pieces of paper
2. Everyone sketches a solution (or prototype idea) to your chosen problem for one minute
3. Repeat this 8 times for different ideas
4. Get everyone to share their ideas
5. Use dot voting to pick ideas to develop further

The goal is to push beyond your first idea, which is often the least innovative, and create a variety of solutions. It’s a fantastic method to push the boundaries on what’s possible. You’ll get ideas you wouldn’t have arrived at by other means, and get the whole team working collaboratively.

Reflecting on my own practices 

Overall I learnt a lot from Ruth’s presentation and I’ve since been reflecting on my own ways of working. I’ve already started to use exercises to check in with my team to get a feel for how they are as a group. It’s given me insight into their emotional wellbeing that I didn’t always have before. I’m able to identify any areas of concern and provide that valuable support when it’s needed.

Next up I’m planning to use fast 8s in a design sprint we’ve got planned on the next feature of our product. Brainstorming multiple ideas quickly and aiming for one or a few to be prototyped and tested with users will help us find what we want to focus on next.

One reason I joined Made Tech was to be part of a community of delivery folk. I love that I have that, and more. There’s so much value in a community of practice. As a group we have great people to learn from. We’re able to try new techniques and tools and share back to the community. 

If you’d like to join the next Citizens Advice delivery event, get in touch with Sam Sharpe, Lead Delivery Manager at Citizens Advice.

(Thanks to Richard Clarke for all images)

The post Facilitation methods to engage teams appeared first on Made Tech.

This process brings together design thinking principles with agile methodologies. And it’s become increasingly popular in recent years as more and more teams have shifted to remote work.

But what benefits come with working remotely?

When we think about remote design sprints, one of the biggest perks is that they can be completed in a short period of time. This is often a lot quicker than a more traditional sprint and encourages teams to work quickly and efficiently – meaning a greater sense of focus and momentum. Win-win, right?

On top of that, remote design sprints can also be much more inclusive. They allow people in different locations and time zones to collaborate in real-time. This diversity of thought and perspective can lead to building more creative and innovative things. 

Getting into the detail

Now let’s get into the need-to-know details of design sprints. For those in the know, a remote design sprint follows the same basic framework as the Google Ventures (GV) and AJ & Smart Design Sprint 2.0. Our goal remains the same – rapidly prototyping and testing new ideas in a compressed timeline. Here’s a few ways a remote sprint is a little different:

• adapted tools and techniques – some of the tools and techniques used in the traditional design sprints may need to be adapted or replaced, but this is easy enough – swap out your post-it notes for remote brainstorming and prototyping tools like Miro
• scheduling – because of the lack of in-person interaction, it’s important to remember breaks and rest to avoid fatigue and burnout
• limited environment – working remotely might mean team members have limited access to physical resources

Overall, a remote design sprint offers a unique approach to problem-solving that supports collaboration and digital innovation. It’s a powerful tool for teams that are distributed across different locations or those who can’t work in-person.

Remote sprints at the Met Office

To help you visualise how remote sprint might work in practice, let’s take you through a week with a client – the Met Office. The aim was to start the process of designing a new careers site for them. They wanted to improve accessibility and showcase their tech, engineering and meteorological careers.

Day 1

Day 1 set the foundation for the rest of the sprint. This involved online meetings to:

• define the sprint goal – the problem we were working to solve
• map the end-to-end user journey – we then chose the part of the journey to focus on for a minimum viable product (MVP)
• capture expert insights – after speaking to Met Office stakeholders, we noted potential challenges and opportunities through “How Might We” statements
• run a 4-step sketch process – everyone noted something interesting from our progress. We then turned our notes into ideas by sketching them. We did this through the following activities:

We used a few activities in sketching. We did crazy 8s, taking one idea from the previous sketches and iterating it. And we did solution sketches, where everyone took their idea with the most potential and converted it to a self-explanatory sketch with a paper prototype.

Day 2

On day 2 we focused on reviewing the sketches from the day before and deciding which one would be made into a more high-fidelity prototype. This was done by:

• heat map voting – where everyone has 3 votes each to pick the solutions or features that they liked best using a Mural board
• speed critique – each team member explains their solution and the reasons for doing it that way
• super votes – the product manager and product owner picked the solution they wanted to take forward

In the end, 3 were picked. These were used to storyboard the user journey, providing a screen flow for the prototype.

Day 3

Day 3 is when things really started to ramp up, particularly for the user-centred design and research members of the team. Our designers created a working prototype in Figma (an online collaborative design tool) which included content to guide the user through the process of applying for a job. 

As the prototype evolved, our user researchers put together the testing plan and recruiting testers. The hard work paid off and apart from a few last tweaks, we had a working prototype by the end of the day!

Day 4

Day 4 was all about testing. We took 6 people at various stages in their careers through the prototype. We asked questions along the way about what they thought, what they’d expect to see and how they’d expect the page to behave. 

Even before analysing our findings from these online interviews, we got a sense that the prototype was already performing better than the existing website did in round one of testing. We could also begin to see common threads of insight and uncertainty run through each session.

Day 5

Day 5 was analysis day. We recognised common themes and patterns emerging from the testing and used them to iterate the prototype. This process is crucial for making sure the team’s prototypes are grounded in user needs and feedback.  

The findings were then presented to the Met Office stakeholders and the rest of the team. This was our opportunity to showcase everyone’s hard work and collaboration, to share insights and findings and gain buy-in and support for the solutions developed.

What’s the verdict?

The main benefit of doing the design sprint remotely was the ability to bring together a widely spread team and work quickly. We were spread from Exeter to Newcastle and many other places in between. Working remotely was more cost effective and a better use of time than having everyone travel to one location.

All this was made possible by technology. Applications such as Google Meet and Mural supported effective collaborative working and communication. And tools like Slido helped us host fun icebreakers. 

The Met Office team who joined the design sprint enjoyed the process and found our team to be positive and motivating. It was great for us to get a more detailed look at their expectations for the site and they were impressed with the speed in which a remote design sprint can turn a set of requirements into an MVP prototype.

If you want to learn a bit more about remote design sprints you can watch our recent webinar where Steven talks about the advantages, disadvantages and surprises in more detail. 

The post Making remote designs sprints work for you appeared first on Made Tech.