Transcript of "Service Design, with Fritz von Runte"

[Intro Music]

Clare: Hello and welcome to Making Tech Better, Made Tech’s fortnightly podcast bringing you content from all over the world on how to improve your software delivery. My name is Clare Sudbery, my pronouns are she and her and I am a lead engineer at Made Tech.

For us at Made Tech, the most important people are the users, so I was very pleased to get the opportunity to interview service designer Fritz Von Runte. He is the ex-Head of Design at the National Institute for Health and Care excellence, otherwise known as NICE. He specialises in improving public sector services.

Clare: Hello Fritz!

Fritz: Hi Clare!

Clare: Hello. Fritz has been doing some work for Made Tech in the – actually, I’m not going to attempt to describe your job, Fritz. I’m going to ask you to do that. How would you describe your role?

Fritz: Well, I’m a designer, but what I am usually paid for is to do service design. But to me, design is the same.

Clare: Let’s talk about service design. The first question for me is what do you mean by service? Because that word can have different meanings in different contexts. What is a service?

Fritz: A service is a fundamental part of everybody’s lives. If you need to pay a bill, if you want to foster a child, if you want to get a license to fish or if you want to renew your passport, all of those things are services. All of those services were designed, not necessarily well designed and not necessarily by a person that calls themselves a designer, but every service in this country has been designed. What I do is try to improve those services by applying some design techniques.

Clare: Fantastic. Service design is a particular area that has been really growing recently, hasn’t it? I’d say maybe in the last few years it’s become a thing that people are paying more and more attention to. What key skills or roles do you need on a team to facilitate really good service design?

Fritz: I think when we talk about service design in government in the UK, we talk about GDS. When we talk about GDS, one of the things that we do especially in discovery, is to understand what kind of team we are going to need in alpha and beta. So, things are not set in stone. You have a multitude of tools, you have a multitude of methodologies that you can apply, and you have a multitude of disciplines that you would use for a particular project. I work with multidisciplinary product development or design. I like working with different people from different areas, different disciplines. That changes service to service.

For example, now we are doing some work with the Home Office about their digital tools and the way people interact with them, and the way people talk to each other using those digital tools. We’re talking about Office and Dropbox and Google and all of those collaborative tools. This is the sort of work that doesn’t require a lot of coding. For example, my team would have a Delivery Manager, maybe a Technologist or maybe a Technical Lead, to have them involved in some technical discussions. Other pieces of work are absolutely a hundred percent digital. For example, if we were to work with the passport online renewal service, which is basically a website where you put in information, then I would have some Engineers in the team to help me navigate those problems and get me some answers.

Clare: Yes, that’s interesting. Just for the benefit of our listeners, in case people don’t know, GDS stands for Government Digital Service, and that is the framework that most government services follow when they are doing any kind of digital work. It’s really interesting that you talked about the idea that you won’t necessarily always have developers involved, because you might be working with a service that is purely using things like Microsoft Office products or Dropbox. They might not be writing their own code. Because I am an Engineer, I forget that kind of work ever even happens. When I’m involved, we are always also writing code.
Those services don’t necessarily have to have that, do they?

Fritz: No. Also, it’s important that we understand that not all services are going to be digital. Service design is not necessarily a digital solution. It will be, in a vast majority of cases because it frees up people, they don’t have to go to places physically, you can do things online and it’s easier, but it’s not a rule. It won’t happen a hundred percent of the time.

I’ll give you another example, I’ll give you the problem. I was working in a commercial company that acquired this transfer logistics company. The transfers were all over the world, from airport to hotel. Basically, it’s a network of taxis. One of the things that we’ve done to improve the service was simply to distribute to all of them clipboards with the brand of the company, with the logo. That reduced the number of missing transfers dramatically, like a hundred to one. Because in places like Egypt or Japan or Kuala Lumpur, where people didn’t know exactly how to write or the name of the company or they had problems finding a piece of paper and pen because the taxi drivers are sometimes not prepared to do that when they get to the airport. So, it was one hundred percent non-digital, this particular improvement to the process.

Clare: Interesting. But when it is digital…

Fritz: Yes, let’s talk about digital.

Clare: … how much collaboration is there between service designers and software engineers, for instance?

Fritz: If we are dealing with a service that is already digital, it’s fundamental to have technical people from the beginning. Recently we have done an amazing piece of work for Citizens Advice. Citizens Advice is an amazing organisation. It has loads of service. We had the privilege to work on one of them. We had a technical lead on the team from the beginning. The sooner that we had this knowledge being applied in the team, the better for us. We don’t wait until the last minute.

Clare: Yes, exactly. I’ve definitely seen – there can be a temptation to think that a service designer is a designer, it’s their job to design a system and then give it to engineers to implement. But when you do that, you remove the conversation, the collaboration. It means that you don’t get that technical input because there’s knowledge that might help. Also, you lose it in the other direction, don’t you? The technical staff need the input and need to have constant conversation with designers.

Fritz: It’s a concept that I hear a lot in my career as a designer. The idea that people have that designers are artists, it’s a misconception, I think. One of the problems is the word design means so many things. When you say I’m a designer, people think you are an artistic designer. Design as a professional is not art. Art is something that comes from yourself.

The designer that is an artist, that goes into the back room, designs the whole thing, and then says build it, this is not the sort of designer that I am. The design that I do is a technique to facilitate projects to happen, really.

We were talking before about GDS. GDS use the best design practices and then they made it into policy, for people to have a standard way of designing services and products and digital products. This rule has existed since Bauhaus, since a long time ago: First you learn what the problem is, then you iterate or you ideate, then you validate. This is what we do with GDS. First you have discovery, then you have alpha where you experiment a little bit, and then you have beta, when you are testing it.

Clare: When you and I were talking about setting up this interview and I asked you whether there was anything that would help me to prepare, you mentioned Lou Downe, which is really interesting because our previous episode with Meri Williams, she also mentioned Lou Downe. I know that her seminal book Good Services is very popular amongst service designers and has been very influential in the whole field of service design. I know she offers training as well, which was another thing that Meri recommended.

In her book, she outlines the fifteen principles of good service design. I’m not going to list them all, but they include things like enable each user to complete the outcome they set out to do and require the minimum possible steps to complete. When you’re designing a new service, what are the most important activities you can do to make sure that you are addressing those principles?

Fritz: I think as a designer, the mindset is always to achieve those principles. She managed to encapsulate all of these things in one simple book with some examples. Also, Lou gives you some ammunition to talk to people that don’t understand our world, the digital world, technical or non-technical. The bigwigs, the senior management in the public sector, for example.

To enable each user to complete the outcome that they set out to do is the most basic thing. If the service is to renew a passport, if the user can’t renew a passport, which is the outcome they set out to do, you are failing as a designer, right? So, this is the most basic. It’s about framing what’s important. We worked with the academy transfers for the Department for Education, a service that was helping academies to be transferred. It’s something that people in education know a little bit too well. If the academy weren’t transferred, or if they didn’t know how to get to the end of this service, it would be a bad thing.

With this piece of work with the Home Office, for example, the idea, the intention of the discovery is to improve the communication of the users. Of course, it’s very easy to understand why they need to communicate because it’s a 38,000 people department that work with each other making intelligence. Conversations happen every day, all day between most of these people. So of course, it is important for them to have this communication in the easiest way possible.

The mindset is always there but require the minimum steps to complete is an interesting one. Basically, good design is almost invisible. We want to make it happen in the smoothest way possible, so people don’t get aggravated or delayed or demoralised or any of those things.

Sometimes the work of a service designer – and this is quite controversial, especially to engineers – but sometimes the work is about turning off some things that are either redundant or that could be absorbed. I can give you one example in the service journey. We discovered that there was a team of 5 or 7 people that were paid handsomely, maybe £40k, £50k a year, just to send a letter that had absolutely no legal value or efficiency. This letter was sent to maybe 20 people per year. These 5 people’s work was mainly to look at data throughout the year, to find those 20 people, to send them a letter that had very little value. We never fired anyone, we just rearranged them into different parts of the service. It’s a bit like a game, you hear something and then you pass it on to the other person and then there is all of these chains. When you have the big picture, you understand that one of these chains is redundant or low value or it is detrimental to other chains that are happening later. So maybe by changing the way this particular moment or process or person acts, you can improve the service. It’s quite an interesting subject.

Clare: What techniques can you use to get that big picture? Let’s say you have arrived at a brand-new green field project, what is the first thing that you are going to do to try and identify things?

Fritz: Well, this question has two answers. You have what everybody does, and what I do. I am a different person.

Clare: Okay, give me both answers, I’m intrigued now.

Fritz: What a service designer does is to identify the ‘as is’ service. Very frequently, this service is not as straightforward as one would think. People say things like, ‘It’s very easy, you do this and then they do that and then you do that and then that happens.’ Identifying the ‘as is’ is quite important. You map everything that happened, the errors, the mistakes, the fumbles, the people that don’t complete the service. We want to understand everything all as a single process.

This is usually the way you start to think of improving or redesigning. There are very few opportunities to start a service from the ground up. Most services exist. So usually, you are refining or improving a service. Now, what I like to do personally when I start on a service, is to identify the naysayers quietly but actively. Naysayers are not enemies, they are just, in my mind, interesting obstacles. They are people that I am going to have a lot of fun when I manage to convince them. Or to be convinced that there is a different way to do things. Maybe they convince me. It’s not an ego thing. That’s the exciting part, for me.

Clare: So, once you have identified the naysayers, how do you then go on this journey with them?

Fritz: I’m going to give you all of my secrets now. I think this is the biggest cue in design is not mapping, it’s about bringing people on the journey with you and winning hearts and minds to accomplish something that would be good for the users or the citizens or the users of the service in general.

One good thing with naysayers is that if I am right and they are wrong, the mindset that I have is that they are not malicious people, they just don’t know something that I do know. The more I bring them to meetings, the more I bring them to see user interviews, the more I bring them to see technical debates with people that know more than both of us, the more they will be aligned to my way of thinking.

If they are right and I am wrong, I want to understand why. I want to do well, so to me it is about getting the best outcome for the users. It’s not about getting my opinion or your opinion or their opinions, it’s about getting the best possible solution for the users. This is why I find it so exciting to work with naysayers.

Clare: That’s what is really notable about Lou Downe’s principles, and generally about service design, is that it is really all about the user.

Fritz: Oh yes.

Clare: That sounds obvious, but it can be very easy to forget about the user because particularly when you are an organisation that is delivering a service, you see it from your point of view. You are thinking about how are we going to get a piece of paper from A to B, or how are we going to make sure that the finance department knows what’s going on, or how are we going to manage our own resources and manage our people? It can be so easy to get so focused on all of that that you forget that actually, what you’re doing is delivering a service. Actually, the people that are really going to be impacted are the people at the other end of this. Service design as a principle or as a discipline is very much about focusing on the users, isn’t it? Making sure that they get what they need?

Fritz: Yes. I say every design is about the users. Design is a technique, not a form of self-expression. Not Phillippe Starck making a lemon juicer that looks like a spaceship from the 1950s. As you try to accomplish something that will please someone, that will help someone to accomplish something, it’s always about the users.

If you’re doing furniture design, for example, you need to understand who is this furniture for? The audience in Japan is very different than the audience in Sweden. The audience in Japan sits in a different way from people in Sweden. They have different heights, they have different body weights, they have different torsos. On average, of course. They have different tastes, different disposable money to buy things.

Also, if I am producing something here and sending it to Sweden, it has a different cost than sending it to Japan. People in Sweden are more concerned about the environment and materials. Maybe I will do a leather chair for people in Sweden. Maybe I will do a plastic one for people in Japan.

Understanding the user changes everything. Understanding the price point, understanding the cost. This goes with everything.

[Music Sting]

Clare: While I’ve got your attention, let me tell you a bit about Made Tech. After 21 years in the industry, I am quite choosy about who I will work for. Made Tech are software delivery experts with high technical standards. We work almost exclusively with the public sector. We have an open source employee handbook on GitHub, which I love. We have unlimited annual leave. Bat I love most about Made Tech is the people. They’ve got such passion for making a difference and they really care for each other.

Our Twitter handle is @madetech. That’s M A D E T E C H. We have free books available on our website at madetech.com/resources/books. We are currently recruiting in London, Bristol, South Wales, and the North of England via our Manchester office. If you go to madetech.com/careers, you can find out more about that.

Here is a quick reminder that before the break, we were talking about how every design is about the users, and users are all different.

Clare: So, how can we ensure that we are delivering what the user needs? How can we get the user involved in that journey?

Fritz: Great question. Without user research, we are coffee drinkers with a new MacBook, that’s what we are. User research is quite important. People tend to think that user research is a complicated thing. It isn’t. It’s a process, it’s a methodology that we know. We do it all the time. If I asked you, Clare, to show me how when you go to Costa or Starbucks and you want a little bit of sugar in your coffee, how do you open the sachet, please? Can you show it to the camera, and I will describe it?

Clare: I’m imaging a long, thin, paper sachet. Obviously, they vary. I’m going to rip the end of, just the end, and then pour.

Fritz: And then pour. Okay, so what Clare did then was she made a movement like someone is ripping a piece of paper. If I went to the actual coffee shop to see her do that, I would see you doing one step before that, which is this one.

Clare: Ah, the shaking! Yes!

Fritz: The shaking. The shaking is the centrifugal force to push all of the contents of the sachet to one end, so the other end is empty, then you put the contents in the coffee. You don’t rip it in the middle and then try to put both halves. If I asked you, what I just did, ‘What do you do?’, you give me one answer. When I see you doing it, I have a more complete picture. There are other techniques we use apart from user research.

A Day in the Life, or we observe people in action. We go to the passport office, for example, in Liverpool. We see people applying for passports, we see the amount of people there carrying a baby, the amount of people there who don’t have a phone. All of these things matter a lot. Accessibility is something that we start from the beginning. Services need to be inclusive, it’s paramount for us to continue any work.

Clare: Yes. One of the things that you talked about was observing people. You asked me, and I only talked about tearing the top off, but if you had watched me, you would also have seen me shake the bag first. I know that one really powerful technique is to watch people using software. Then you actually see how they interact with it. Particularly to get the engineers to watch people using the software that they have built, so that they can understand that people don’t necessarily use it the way that they thought they would.

Fritz: Absolutely. Yes, so this is more user testing. Observing what you are doing, and constant rapid iteration and rapid improvement of things is paramount. It doesn’t need to be that complicated.

Clare: User testing is very important, isn’t it? Once you’ve actually built something, as soon as you’ve built something, you then want to get it in front of those users. So that you can then find out is this what you had in mind.

Fritz: I am a big fan of rapid prototyping. If we were talking about a digital product, I would be in a meeting room with you, the other engineer, the delivery manager, whoever else. The user researcher. We would be trying to put on paper, rapidly, a sequence of events to see if it makes sense in technical terms. Then we leave the meeting room, we go next door, we talk to the people that work in a completely different area, like finance. We show them a couple of screens. The amount of gold that you get just by showing it to people around you. People say, ‘I don’t know what you mean by this button here, what does that mean? What does ‘Download’ mean? Why am I downloading?’ Because sometimes you are too involved in your own process. You don’t know that there is some inherent knowledge to something that you are trying to work on.

Assumed knowledge is something that I think a lot about. Also, I think about desire paths. The ways people want to do something, as opposed to the ways you planned for them to do them.

Clare: Yes, I know that desire trails is something that architects talk about. It’s something that happens in public spaces. If you landscape a park, after a park has been around for a while, new paths will appear that weren’t landscaped and haven’t been tarmacked, going across bits of grass. Those are the desire trails. Those are what the users really want to do.

Fritz: Exactly, that is a term that is borrowed from urban design but it’s all design, at the end of the day. But that is exactly it, you nailed it.
One good example of this is that especially people with iPhones, instead of downloading a photo and sending it to someone else, they don’t know how to do all that. So, they simply screenshot whatever photo, and they send a screenshot of the photo, which is crazy, but it works!

Clare: Yes, people find their own ways of doing things.

Fritz: Exactly.

Clare: I was thinking about how users interact with products, and I remembered the wonderful tool of the heat map. I love looking at those. For instance, you might have a website and you can track how users are interacting with that website. You can see that most of your users are going to this button as soon as they arrive on this page. Or most of your users are hovering around the bottom left corner, for some reason. You can see where their mouse is going. Sometimes that is exactly what you expect, and sometimes that’s a surprise. Why is everybody going there? What is that? That can be really useful information because it shows you whether users are interacting with your thing in the way that you thought that they were.

Fritz: Yes. This is a duality between qualitative data and quantitative data. The quantitative is what people are doing. The qualitative is why people are doing that. That sort of insight, for example heat maps or analytics or this and that, it’s really a fuel for qualitative research. So, you get six to ten people, and you ask, ‘If I show you this website, what do you see? What do you do?’. Then you see people going to the left. ‘Why are you going to the left?’. You need to hear it from the horse’s mouth. Why are they doing that? The danger that I have seen happen many times is a hippo. Do you know what a hippo is?

Clare: A hippopotamus? Is it something else?

Fritz: No, it’s the Highest Paid Person in the Office. It’s the old mentality that the highest paid person in the office has all of the answers. It’s usually a man and he usually knows it all. It’s infallible. They need to know, and they need to be right all the time, otherwise they cry themselves to sleep and question their masculinity. You get these people, ‘They are going left because they can’t find the button. Make the button bigger!’. You can make the button half of the page, but if they don’t have any interest in clicking that button. They don’t understand the reason, they don’t have to click on the button, they will not click on the button.

It’s not about making it bigger or blinking or red. Data is quite important, but data needs to be three dimensional. So, only quantitative data gives you insights to ask questions on qualitative data.

Clare: Got it. Right back, a while ago, we were talking about how when you are starting a new service, you want to map the process as is. What techniques can you use to do that?

Fritz: Usually what I do is I try to have a few conversations with the team and the stakeholders, to understand the general idea. Then I put something together, just as a sandbox, really. These days we’ve been working remotely, I use Miro, which is a collaborative tool. I get all of those people in a room, virtual or not, then I ask them to try to rapidly tell me all of the events that happen in this service. For example, the user wants to book a holiday. The airline company asks for a passport, they check the passport. They see it’s not valid anymore, then they Google “How do I renew my passport?”. They get this page etcetera. We try to map those things and then I try to dive deep into who is responsible for each process.

In service we have something called front of the line, back of the line, and touchpoints. Touchpoints are the points at which the user interacts with the service. Front of the line and back of the line are the things that happen without the users knowledge or participation. In each one of those processes inside a service, you have a series of tasks. These tasks usually have an order. For example, when you go to B & Q, and you buy loads of painting supplies and a gallon of paint and a tray and then you pay. Then after you pay, they say, ‘Would you like a bag?’ You say, ‘Yes please, there’s a lot of things for me to carry’. ‘It’s 20p.’ Why didn’t you ask me that before I paid, now I need to find a coin, or to pay a credit card fee of 20p, which is a waste of energy and effort. It’s a pointless exercise.

So, the order of the tasks is quite important inside the process. I go and talk to them. I say, ‘Clare, I understand that you are the cashier, and you do this, this and this. Is that correct?’. You say, ‘No, I don’t do that because usually users get frustrated when I offer them a bag after they pay.’ Sometimes people redesign the process because of experience.

Clare: Yes, so it has already been changed.

Fritz: Yes. It’s a multidisciplinary exercise, to answer your question in one sentence.

Clare: Absolutely. We’ve totally run out of time! I’m going to quickly run through the questions that I ask every guest. The first one is who are you inspired by in this business?

Fritz: I used to be inspired by the people that trained me, like Abi Colvert, Elise Rieshott, Jeff Gothelf. I quite like this guy called Dana Reali, but recently over the last five years, I became more and more interested in people that are doing what I do but better than me. Like Lisa Jeffries, like Kit Collingwood, like Claire Moriarty. Well, Claire isn’t doing what I do. She is in leadership; she is changing the world. She is a huge source of inspiration.

Clare: Brilliant, thank you. We’ll put all of those names in the show notes for this episode. My next question is, tell me one thing about you that is true and one thing that is untrue. So, a truth and a lie.

Fritz: I was trained as a cook in Japan for two weeks, and I know the national anthem of Israel by heart.

Clare: You were trained as a cook in Japan, did you say, for two weeks? What did you learn?

Fritz: To cook. To cook Julienne carrots and how to do Udon noodles and how to do an egg in boiled water. Small things.

Clare: And how do you know Israel’s national anthem by heart?

Fritz: When I was maybe 10 or 11, I went to 13 or 14 different schools. I was always changing schools. One of them was an Israelite school. They had the anthem and so I learned it. I studied there for six months; I think.

Clare: Both of those sound entirely plausible. Last question, or nearly last question. What is the best thing that has happened to you in the last month or so? It could be work related, but it doesn’t have to be.

Fritz: I think it was coming to this project with Made Tech and the Home Office. I think it is a very interesting project that has very big ramifications. It’s a project that is going to continue for a number of months, so I’m quite excited about that. I have loads of friends at Made Tech and loads of people that I admire here. I like working with good people.

Clare: Fantastic. What is the project, are you allowed to say?

Fritz: I would rather not. I spoke a little bit about the discovery that we are doing with the digital tools that they have but there are many other projects involved with for the Home Office, where we are helping them. This is not the only one. The other ones, I would rather not speak about, just because I don’t know enough yet.

Clare: That’s absolutely fine. Very last question: Where can people find you and do you have anything coming up that you would like to plug?

Fritz: People can find me on Twitter @vonrunte. The only thing I have to plug is a floor lamp that I am designing that will light up a plug on the wall to see if it works.

Clare: Von Runte is V O N R U N T E, isn’t it?

Fritz: Perfect, yes.

Clare: Fantastic. We are out of time but thank you very much for talking to me.

Fritz: Thank you Clare.

Clare: As always, to help you digest what you’ve just heard, I’ll attempt to summarise it. Services are journeys offered to you by organisations. For instance, applying for a passport.

All services are designed, just not necessarily by someone who calls themselves a designer, or uses conscious design techniques. Service design can involve a multitude of disciplines depending on the project.

Not all services are digital but when they are, technical staff and designers need to collaborate constantly. It’s a two-way street. Design is not art. Designers are not building what they want to build. They are building what people need to use. Good design is almost invisible. Sometimes it’s about removing stuff rather than adding it.

In UK Government, the trailblazers for service design have been GDS, the Government Digital Service. GDS have adopted great design practises and then standardised their approach across the public sector in the UK. This starts with the discovery phase, where you learn what problem you are solving. Then alpha, where you experiment a little. Then the beta phase when you are testing your service. Finally, you go live. Lou Downe’s book Good Services is a great introduction to service design. She outlines 15 principles of good service design. This is not the first time one of our guests has recommended this book.

When starting a new project, start by defining the as is service. Map out every step. Check with the actual people doing the job, don’t take the word of people who are not hands on. Or start by identifying the naysayers and winning them round or letting them win you round.

At the end of the day, it’s all about the user. With each service you are helping a user to accomplish something. Understand that all users are different. Observe them as well as talking to them. Remember that rapid prototyping is a powerful tool to identify any misunderstandings or assumptions about what the user needs and expects.
That’s not the end of the podcast, stick around for extra content.

Clare: Every other episode, this last short segment will be devoted to story time. Storytelling is useful for teaching, for unlocking empathy, and for creating a sense of shared connection and trust in your teams. I love telling stories to both children and adults. I’m actually a lapsed member of the UK Society for Storytelling. So, the plan is that I’m going to be using stories to illustrate various points about effective software development.

When thinking about good stories to tell, I realised that a lot of my favourites aren’t necessarily appropriate. Like when I was a high school maths teacher, and I told my year eights that all maths teachers are a bit anal. I’ll leave it up to your imagination how a class of teenagers might have reinterpreted that one.

But then I thought of this story, which is not only safe for work, it’s also a mystery. It’s involves a tiny cottage that I know. If you can picture the setting, it’s very remote. It’s at the foot of the slopes of Sca Fell, which is the highest mountain in England, in the Lake District. At night you can hear the owls, and you have to mind your feet for toads when you go to the loo. It’s belonged to the National Trust since the 1960s, when it was run by a colonel who would berate the people who stayed there for not polishing the silver when they left. You can still stay there, and I do.

The mystery concerns some journals. There’s no TV and no internet. So evenings are spent in front of the fire reading, and writing in the cottage journals. People write fiction, or they write about the adventures they’ve had. For instance, the family that were woken up at 5 am by a father and two small children who’d been stuck on the mountain overnight.

People draw pictures, people swap tips on the archaic plumbing, and they write about how much they’ve enjoyed reading about the colonel in the original sixties journals. But I was thinking, “What sixties journals?”, and recent entries were complaining because those journals had gone missing. And I became obsessed. I hunted everywhere, but they had disappeared. And then I had an idea. Maybe I could use the journals to find the journals. It was difficult. There was no search function. I was having to page through a lot of handwritten entries, but I managed to find the last mention of the journals before the first complaints that they’d gone missing.

And that last mention was saying, “It’s disgraceful. they’re in such a state. I’ve half a mind to take them home and fix them.” Now, this person had left an initial, a surname, a town (Cambridge), and some hints that suggested they might be an academic. So, I Googled, and I found a possible candidate and an email address. And then I stopped. Okay. What if it had been me that had taken the journals away to fix them? And then I probably wouldn’t get round to it and then I’d feel guilty. And then it would get harder and harder to return the journals.

A whole year had passed. So, what I did was, I sent a friendly email making it very easy for them to send the journals to me so that I could return them to the cottage. And then I waited, and I waited, and I gave up.

I didn’t even know I’d got the right person. I forgot all about it. And then a couple of months later, a mysterious parcel arrived on my doorstep. And I had no idea what it was until I opened it and found the journals.

Now, the lessons I think that are in this story are many. One of them is about asking questions and being curious and being prepared to dig a little and be creative, to find an answer to a problem. There is also something in there about tenacity – not giving up. But also, about empathy and forgiveness and seeing things from somebody else’s point of view. And finally, there’s the principle that if you want somebody to do something, you have to make it easy for them. This applies to our teams. It applies to our users. Low friction processes are the way forward.

[Music sting]

Clare: Working in the public sector means that at Made Tech, we really care about making a difference. For this final, Making Life Better segment, myself and my colleagues will be sharing suggestions for small things we can do to make the world a better place. For this episode, this comes from Chasey Davis-Wrigley, who is one of our lead engineers at Made Tech.

Chasey: I have found that a rewarding way of helping out my local community has been by doing some volunteering and organizing some fund-raising events. The events work really well around my work commitments and my family. They can be one of the things that the whole family get involved in. Prize Bingo evenings for a local mental health service, strawberries and cream stalls at local carnivals for Citizen’s Advice Bureau, Halloween discos for the local food bank. There are so many things that you can organise, and they really help make a difference to people’s lives in your local community.

You make a lot of friends in your local area and meet new people and you have fun, too.

[Music Sting]

Clare: And that’s the end of another episode. If you are enjoying the podcast, please do leave us ratings and reviews because it pushes us up the directories and makes it easier for other people to find us.

I’ve got a few talks coming up. You can see the details on my events page on Medium, which is linked to from my Twitter profile. You can find that at @claresudbery, which is probably not spelled the way that you think. There is no ‘I’ in Clare, and ‘Sudbery’ is spelt E R Y at the end, the same as surgery or carvery.
You can find Made Tech on Twitter @madetech, M A D E T E C H. Do come and say hello, we are very interested to hear your feedback and any suggestions you have for any content for future episodes, or just come and have a chat.

Thank you to Rose, our editor, and to Richard Murray for the music. There will be a link in the description. Also in the description is a link for subscribing to our newsletter. We bring out new episodes every fortnight on Tuesday mornings. Thank you for listening and goodbye.

[Recording Ends]

Back to the episode