People in the lead

Local Welcome puts people in the lead. We run meals across the UK that are led by groups of leaders from local communities. We change and shape our meals and our organisation in response to feedback from our leaders, members and guests. Our meals have a distinctly local feel despite us being a national charity.

The Lottery, who fund us, care about people being in the lead. “When people are in the lead, communities thrive” is how they put it. It’s true! Our meals attract new people to leadership, increase the confidence of leaders, build connections that didn’t exist before, and reduce loneliness and isolation for the people that come. These things help our communities thrive.

But “people in the lead” is not always a straightforward concept for us. Although we do put people in the lead at Local Welcome, we’re also clear that it does not mean:

  • letting people do whatever they want

  • responding to everything people say

  • giving people control over strategic decisions.

This sounds counter-intuitive, like maybe people are not in the lead at all. I get that. I’ve been grappling with this tension for a decade as a user-centred designer who tries to balance the needs of people against the goals of organisations so that both are met. It’s hard to get this balance right. But it’s important to find a balance.

This post is about how we put people in the lead, where there are tensions, how we resolve these, and where we need to do things differently. This isn’t the only way to think about people in the lead (far from it!) but I hope that sharing what we’ve learned at Local Welcome is helpful.

People lead our meals, but there are limits to their power

People lead Local Welcome meals, specifically a small group of leaders who all live within a mile or two of the venue. Four leaders turn up at 11am to set up the space and lay out the food. From noon they welcome everyone and lead the group through cooking, eating and tidying up. Then they close up and leave by 3pm. 

Our leaders are in charge for those four hours. They take control of activities. They set the tone and resolve conflicts between people. They fix problems when the food doesn’t arrive. They are our people in the lead.

But putting people in the lead doesn’t mean they can do whatever they want. There are clear boundaries because often the best intentions of individual leaders conflict with the wider goals of Local Welcome.

For example, we want diverse groups of leaders. We have designed Local Welcome to open up leadership to as many people as possible. One way is that there is no hierarchy of leaders in a group - so we can minimise the way that power dynamics too often favour the bold. Another way is that we limit leader involvement to four hours each month - so we can maximise the chance that those with busy lives will feel just as much a leader as those with more free time.

So when a leader starts assuming overall control, or starts tasking other leaders, we ask them to stop because we can’t attract a diverse group if certain types start to dominate. Or when another leader spends hours preparing extra food for our meals, even though we love their intent, we ask them to stop because we worry about losing leaders who can’t put in extra hours and feel guilty as a result.

This is just one example of a tension around people in the lead. There are many others. Our leaders are in charge, but with limits to their power, because we are balancing individual needs against the needs of the group. I’m not saying we always get it right, but we do spend time working out the boundaries and being clear.

And, honestly, there are some leaders who chafe against these boundaries and leave Local Welcome. That’s OK. There are lots of different ways to lead in your local community and our meals are only one of these. 

We’re led by people’s feedback, but we don’t always react

People lead the constant evolution of Local Welcome by giving us direct feedback. Not just our leaders, but also our members (local people who pay to come) and our refugee guests (people seeking sanctuary who come for free).  

We get this feedback in many ways. It’s important that we never ask people what they like or dislike because avoiding preferences is the first rule of user research! Instead we use these ways to find out what’s causing us problems:

  • Leaders tell us what’s working and not working after every meal

  • Members give feedback by email and refugee guests by text message

  • Our team goes and takes part in meals to observe things in person

  • Third party researchers go out and assess our outcomes and impacts

  • I receive personal emails and people aren’t shy about saying what’s wrong!

We process this feedback every Monday at our whole-team debrief. This has led to changes like printed rather than digital instructions, new recipes, better experiences for first-timers, new methods for tidying up, and countless other improvements.

But being led by people’s feedback doesn’t mean responding to everything that people say. There are three reasons we don’t always act on what we hear:

  1. We have a tiny team of six people. We focus our team only on the things that are most important right now. Lots of problems go unaddressed because they’re not (yet) important enough to prioritise above everything else. We had people asking for new recipes for more than a year before that became important enough for us to spend several weeks responding to recently.

  2. There are some things that only our team can see. Reasonable suggestions (like leaders bringing homemade desserts) are ignored because we’re aware of factors that are invisible to the person suggesting it (leaders bringing food complicates food hygiene and it can make time-poor leaders feel lesser-than). We also ignore suggestions to provide activities for children because we prefer to involve them, not provide a separate creche-style experience.

  3. It’s impossible to respond to every piece of feedback. Different people have different opinions that can’t always be reconciled. Some of our leaders want less structure so that they can improvise more, other leaders want more structure so that they feel secure about exactly what’s going to happen. Both are reasonable, but we say no to both in the name of balance. 

Regardless of whether or not we respond to feedback, we are open and honest with people about what we’re doing. It’s hard telling people that their suggestions won’t get acted on for a while, and harder when we explain that things won’t change at all, but by being clear about our reasons we bring our leaders into the conversation.

And, again, sometimes people leave Local Welcome because we won’t make the change they are asking for. We’re always sad to see people leave, but we’re OK with it as long as our meals keep getting better and more inclusive as a whole.

Strategic decisions are led by our team and our trustees

Finally, there’s a whole area of leadership at Local Welcome where people are not really in the lead. Big strategic decisions like making financial forecasts, deciding which funding to apply for, shaping nationwide growth plans, setting HR policies, or even deciding what to do while we can’t run meals during the pandemic. 

These decisions are led by our team and trustees. Mostly there are good reasons for this, but there are some things we need to change too. 

We are a young organisation trying to find a sustainable operating model and we’re changing what we do when we find out what works. Our priority is to be flexible and iterate our model, and setting up effective systems to involve people fairly requires more stability and headspace than we have right now (also, as we flex and iterate, the types of people that we work with are constantly changing). We think it’s OK to make this trade-off while we establish ourselves. Others may disagree.

More specifically, we are pursuing a difficult goal to become self-funded. We are using technology to support meals in 100 locations each week, which means that our meals have to be standardised in ways they would not be if they were run 100% locally. Managing this tension between local leadership and a national model involves trade-offs. Our team and trustees have experience with these trade-offs, and we sit outside the local context, so we take the lead on these decisions.

Of course, there are ways to involve the people that come to our meals in big strategic decisions. We’re planning to explore models for doing that in the future. But they’re not a top priority for us until we’re more established and scaled up.

What is a top priority for us is to improve the diversity of our team and trustees. We think it’s OK for our team and trustees to lead on big strategic decisions as long as we are representative and diverse. But we could be doing better on this because our team is mostly white and our trustees are mostly men. We’re currently finalising fair policies for pay and HR (we’re proud of these!) to go with our inclusive approach to recruitment so that we attract applicants from a wider range of backgrounds when we next recruit. We’re about to expand the number of trustees and recruit a new chair through a new free and fair application process too. 

I doubt we will ever get to 100% people in the lead on big strategic decisions and I think that’s OK. But I’m looking forward to working with a more diverse team and a more representative set of trustees in the near future, and I’m intrigued to see how we can involve leaders, members, and guests in strategic decisions one day.

All great slogans contain hidden tensions

Let me try and wrap this up with a personal reflection on “people in the lead” and why it feels important to be honest about the trade-offs it involves for us.

I used to work at an organisation called the Government Digital Service (GDS). One of the core principles at GDS was to “start with user needs”. This was a wonderful, necessary, motivational principle when it was introduced in 2010 because too many government services didn’t think about the needs of users. It’s why I joined GDS.

But, over time, “start with user needs” took on such weight that people ended up making poor decisions by referring only to the slogan, rather than balancing user needs with factors like policy intent, technical feasibility, or budget availability. I spent a lot of time at GDS trying to unpick these decisions and convince people that the real task was to balance these things. A slogan can’t do the hard work for you.

“People in the lead” reminds me a lot of “start with user needs”. It’s a wonderful, necessary slogan. It’s a powerful injunction to avoid perpetuating charities that are run in a paternal, top-down, we-know-what’s-best-for-people way. It’s a helpful framing of what’s been going wrong for too long.

But “people in the lead” contains tensions too. If it means letting people lead without boundaries we run into problems. If it means responding to all the feedback we’ll never make any progress. And if it means involving people in strategic decisions early in the life of our startup charity it creates more overhead than we can deal with.

At Local Welcome we live with these tensions. We care deeply about people being in the lead - our whole model is centred around people leading our meals - but we know we have to balance having people in the lead against achieving our organisational goals. It’s difficult, and we don’t always get it right, but we’re learning.

This post is reproduced here with the kind permission of Local Welcome. Let me know what you think on @myddelton.






Fixing problems with our oral culture

At Local Welcome we work in a lean and agile multidisciplinary team. We plan together, work together and reflect together. It’s the same approach we used at GDS and it’s increasingly common for knowledge workers. 

One way of thinking about this is that it’s primarily an oral culture. Oral cultures are great for rapid product development because people with deep expertise talk things through as they come up. They’re natural and human - you sit together, do stand-ups, chat over the top of monitors (or on Slack), and pick up on body language. Not much is written down because it’s easier to just ask someone.

At Local Welcome we learned that oral cultures have problems too. We’ve learned five ways to move to more of a written culture where it counts:

  1. Live meeting notes make for better meetings

  2. Shared documents collapse distance

  3. Documenting operations improves resilience

  4. Automating is easier if things are written down

  5. Notion makes a better written culture possible

These experiments with written cultures were not about abandoning our oral culture altogether. They were about finding ways to specific solve problems we faced.

Problems with oral cultures

Earlier this year I read about oral and written cultures in Conway's Law: latency versus throughput. It contrasts oral cultures of co-located lean and agile teams with written cultures of distributed open-source software development efforts. It’s a great read.

It made me realise that there are significant problems with oral cultures:

  • Oral cultures struggle when someone goes on holiday. Maybe the person writes handover notes. Maybe their work stops while they’re away. Or maybe they end up doing work while they’re by the pool. None of these are good outcomes for them or the team. 

  • Oral cultures fail when someone leaves. In organisations adopting lean and agile methods the phrase you hear is “knowledge walks out the door”. Organisations often have to do the work again. It hurts morale. It’s one reason modern IT projects get delayed.

  • Oral cultures are fragile when it comes to working remotely. Video calls of talking heads are a poor substitute for meeting in person. Grabbing someone for a chat isn’t as easy. Water cooler gossip moments disappear. These interactions are the glue of oral culture.

  • Oral cultures amplify the loudest talkers regardless of their expertise. Worse, oral cultures can minimise or silence anyone who finds the social context difficult. If we care about diverse perspectives neither of these things are good.

These are serious problems faced by organisations that rely on lean and agile teams. I saw the long-term effects of these when working at GDS and the Home Office. Initial momentum and excitement often gave way to a jaded, unproductive hopelessness.

We found five ways to mitigate these problems at Local Welcome.

1. Live meeting notes make for better meetings

Our simplest and most effective piece of written culture was taking live notes during meetings. Simple change. Huge benefits.

At the start of every meeting we created new notes. We listed topics that we wanted to talk about and prioritised them. Then we discussed the topics with one of us making close-to-verbatim notes as we went.

The thing that made it sing was sharing the live notes where everyone could see them. On video calls we shared the screen with the notes. When we were in the same room we threw them up on the projector.

Doing live meeting notes like this made all our meetings better because:

  • We set the agenda together. Everyone added topics and helped with prioritisation. It brought our divergent ways of thinking out. Meetings meant more to us because we created them together.

  • It kept things moving. The remaining topics were a constant visible reminder of what we hadn’t covered yet. We all got skittish if we sensed we were spending too much time on any one topic.

  • Everybody’s contribution was honoured. There was magic in seeing your words on screen. You felt heard. You were heard. Your words remained even if someone started talking over you. 

  • We could go back and see what was said. Sometimes we scrolled up during the meeting to pick up a missed point. Sometimes we checked in later to re-read a decision that was central to our work.

  • It made it easy to act. Whenever we agreed an action we added it as a checkbox item. Everyone helped by pointing out actions as we went. We sent them round at the end. Stuff. Got. Done.

Of course there were trade-offs. But we found workarounds:

  • Doing semi-verbatim live notes works because you’re not parsing for importance (unlike minutes). But you do have to type fast. Most people type fast enough and everyone gets quicker with practice. 

  • It’s hard - maybe impossible - to make live notes when you are contributing to the discussion. We learned to ask a colleague to step in and note if we started speaking. It worked surprisingly well.

  • There’s no point in live notes that disappear later. All our meeting notes - kickoffs, leadership, all-hands, 1:1s - were stored in Notion sections shared only with attendees. Secure. Private. Easy to find.

  • If anyone can change the notes then anyone can game the notes. We had version control to fall back on. But mostly we trusted that our team wouldn’t do this. What is a team like ours without trust?

I’ve never had such focused and productive meetings as we did at Local Welcome with our written culture of live meeting notes.

2. Shared documents collapse distance

Another part of our written culture was working on shared documents during video calls rather than staring at each others’ faces. It collapsed the distance and made us feel like we were all in the same room.

Let’s back up. Lots of people have been remote working this year. There’s a lazy assumption that working together online means chucking everyone into a video call and hoping for the best. This doesn’t work.

It doesn’t work because it’s not how we work together for real.

When I work with someone for real we’re always looking at a shared document. Maybe it’s my terrible sketch. Maybe it’s a lovely spreadsheet. Perhaps I’m angrily marking up a print-out with a red pen. Or I’m in front of a messy whiteboard drawing squiggles and waving my arms.

The secret to working together is the shared document. Not our faces. (I’m not even sure that body language is as important as everyone says.)

In 2020, shared documents are largely solved for remote work. We’ve got Google Docs, Google Sheets, Miro boards, Notion pages, and so on. Anything where lots of people can work on a single document that is stored in the cloud and see everyone’s edits as they happen in real-time.

That’s how we worked together remotely. We turned our cams off but left our mics on. We all opened a shared document. Each of us interacted with the document using our own computer, our own viewport settings, our own shortcut keys, our own input devices. We felt natural, at ease, and in control. We chattered away to each other in our headphones. And before we knew it two hours had gone by. Without exhausting us.

At its best it was actually better than working in person. We stopped having problems with handwriting (fonts!), running out of space (infinite canvas!), losing work in dead-ends (version control!) or coming in to find that someone had wiped away our precious system architecture.

I’ve been working remotely for nine months. It always felt like working together thanks to our written culture of working on shared documents.

3. Documenting operations improves resilience

The biggest move we made to a written culture was documenting our team’s operational processes. This was a lot of work but it paid off.

We documented our operational processes because we needed to operate our meals service by doing specific tasks at different times:

  • Weekly tasks like briefing leaders or arranging grocery deliveries

  • Monthly tasks like checking leader availability or booking venues. 

  • Occasional tasks like opening a group or inviting a support animal.

  • Event-driven tasks like cancelling a meal or retiring a leader.

We learned that operations work was different to service development. When designing our service the oral culture worked because we could improvise with information in our heads. When operating our service we had to do tasks the same way each time and our oral culture fell apart. 

We started with an information architecture of nine operational areas:

  1. Start a new group

  2. Recruit leaders

  3. Recruit guest partners

  4. Do monthly meal planning

  5. Prepare for a week’s meals

  6. Be on-call for the meals

  7. Debrief and archive the meals

  8. Cancel a meal

  9. Do maintenance tasks

Each of the operational areas contained a subpage for each of the tasks we needed to do. Each subpage had a list of instructions, links, videos and step-by-steps to ensure we did these tasks the same way each time. Any member of the team could update the instructions at any time.

This improved our operational efficiency. But it did something else too. In writing down how to do our own operational tasks we created a manual for others to do them when we weren’t there. Suddenly it was OK to go on holiday without writing handover notes! Bliss.

I’m leaving Local Welcome at Christmas but I know the team will be fine because my processes are documented as part of our written culture.

4. Automating is easier if things are written down

One useful side effect of our written culture is that it became easier to automate the painful and repetitive processes that we’d documented.

At Local Welcome our goal was to design a great service, work out how to operate it, and scale it up to 100 locations. This meant we grew until we ran out of capacity to grow any more. Then we stopped to figure out what we could automate to let us grow again. Over and over again. 

Documenting processes made it easier to automate things in two ways:

  1. It made it clear which operational processes were most painful. “Do monthly meals” involved emailing 100 local leaders, asking for Sunday availability, jigsawing into free slots, sending calendar invites, setting up the meals in Eventbrite and on and on. I only had to look at the process page for about five seconds to realise this was an unsustainable manual process after about 20 groups.

  2. It made it clear how to approach automation. The process page told us what technical capabilities we’d need. Send emails, collect choices via personalised URLs, make allocation decisions with a custom algorithm, use Google Calendar API to create invites, use Eventbrite API to publish events etc. It showed we couldn’t do this without hiring a developer - and what that brief should look like. 

Local Welcome can’t grow without automating lots of things. It’s easier to know what to automate and how to do it with a written culture.

5. Notion makes a better written culture possible

We used a tool called Notion for our written culture. Notion is an intranet tool that actually works. This is a miracle.

Intranets are usually the graveyards of organisational knowledge. They are horribly designed, poorly structured, difficult to use, hard to edit, and impossible to use on your phone. These problems, taken together, mean that all intranets go out of date and stop being used at some point. Even saying the word ‘intranet’ to people makes them shudder.

Notion is an intranet tool that solves these problems:

  • It’s easy to use. If you can use a Google Doc you can use Notion. It has basic text controls and lets you embed maps, videos, images etc. Everything is edit-in-place so the learning curve is minimal. 

  • It’s a multi-editor tool. Everyone can edit at the same time. You see edits being made by people in the same document. There’s no saving things, or checking things out, or any of that nonsense.

  • It’s got just-enough structure. In Notion every page has its place (yes!). Yet it’s easy to move things around by dragging them to a new place. It’s the first tool I’ve used that lets the whole team evolve an information architecture on the fly. It’s a marvel.

  • It’s everywhere you need it. It works on all your devices because it has all the native applications (Android, iOS, Windows, OSX) and a beautiful web interface. It’s cloud-based so it’s always in sync.

  • It lets you recover from mistakes. Deleted pages are easily restored. Each page has a version history that will save you if something goes wrong. This frees people to make changes.

The killer feature that makes Notion work for a written culture is the approach to sharing and privacy. Written culture needs granular sharing and privacy controls. Policies are for everyone. Leadership discussions are for leadership eyes only. And 1:1 notes are just for the 1 and the 1.

Google Drive is a hot mess for this kind of sharing.

Notion has a team area (everyone can access everything), a private area (only you can access) and your shared area. When you share a page with two people it appears in your shared area. Every page you add beneath is shared with those two people (and no one else). Dragging from the team area to the shared area changes the sharing. It makes sharing visual.

Notion made our written culture work because everyone used the same tool for everything that we wrote down. We were all on the same page.

Tradeoffs and mitigations in our written culture

Of course there were problems with moving to a written culture as well as benefits. Every change we made had tradeoffs and mitigations:

  • Writing things down enforced a clarity that talking about things forgave. Spoken words are slippery where written words are not. This often made people feel uncomfortable, especially in the face of uncertainty and ambiguity, and we had to find a way of talking that reconciled this discomfort. Strong ideas, weakly held etc.

  • Some people struggled to write or read fast, maybe because they were dyslexic, or because they weren’t used to doing this. We only asked people to note who felt comfortable and we left extra time for reading (or listening with speech synths). We paid attention to practices that might exclude people, just like with all our work.

  • System thinkers (me included!) often got carried away with building ‘one system to rule them all’. One of the things that kills a written culture is trying to write down everything. We kept the many parts of oral culture that worked for us. We tried to be intentional about which bits of our work would benefit from a written culture.

Despite these problems and tradeoffs we loved developing a written culture at Local Welcome. It made us stronger and more resilient.

Yes, in the short term, it’s more natural and human to ask a question than to look in the documentation. Especially when you realise how much effort it takes to create and maintain good documentation. 

But, in the long term, many of the problems that plague our workplaces - knowledge loss, pointless rework, dominance of loud talkers, porous work/life boundaries - stem from the problems of our oral cultures.

It might be OK for a software team to follow the Agile Manifesto and prioritise working software over comprehensive documentation

But service organisations? I think we need a little more written culture to thrive.

Say hello to @myddelton and let me know what you think. I’m looking for my next product role from January 2021 so get in touch if you have any suggestions! Also this post owes a huge debt to Ellis Pratt who interviewed me about moving from an oral to a written culture on the Cherryleaf podcast earlier this year.

Things I learned at Local Welcome

My contract at Local Welcome ends at Christmas after two years. It has been a wild ride and I’ve loved every minute.

We took a great idea that Local Welcome had been developing since 2015 - bringing local people and refugees together to cook and eat a meal as a way of building community connections - and scaled it into a national service operating in 8 cities across the UK.

Then the pandemic struck and we had to stop doing our meals. Over the last 6 months we’ve accepted that loss and pivoted to two new services - Local Together and ADHD Together - that aim to have similar outcomes.

I learned some big things about product management at Local Welcome:

  1. Riskiest assumption experiments are my north star

  2. Off-the-shelf software is cheap and crazy powerful

  3. Whole-team planning creates shared direction

  4. You’re gonna need a bigger goal

  5. User research with real signups is my jam

  6. People respond best to real people

  7. Written culture makes things resilient

  8. The runway won’t take care of itself

  9. Working with an ADHDer has changed me

I also made some mistakes. I always do. I plan to learn from these in the future:

I’m sad to leave Local Welcome but peaceful because the team’s in a great place to go on without me. I’m looking for a new product role starting in January so drop me an email to myddelton@gmail.com if you’ve got any suggestions!

Now, let’s get into those lessons and mistakes...

Things I learned

Riskiest assumption experiments are my north star

At Local Welcome my role was to take the meals concept that already existed and prove it could be a scalable, sustainable national service. The team had secured funding from the Lottery to do this based on an untested hypothesis that we could operate 100 groups every weekend. 

This was an overwhelming challenge until we broke it down into its riskiest assumptions. That we could run groups in places we didn’t live, charge people to come, train leaders who were not our staff, find and turn out refugee guests, have meaningful impacts etc. 

Once we listed the riskiest assumptions an obvious sequence of work jumped out. We ran experiments to understand these assumptions one by one. They were not simple pass/fail experiments aimed at some kind of scientific truth. They were design experiments to learn what approaches worked well enough to move onto the next assumption. That’s how we built Local Welcome.

There were trade-offs. This approach worked for exploring the big decisions early on in our product. But it created service debt to fix later as a result of all those ‘good enough’ decisions. I was OK with that because our priority was to prove the viability of the service before our money ran out. 

It worked. The Lottery gave us continuation funding in March 2020.

Off-the-shelf software is cheap and crazy powerful

We tried and failed to hire a tech lead when I joined Local Welcome. Actually, we decided not to hire at the last minute because we realised we didn’t know what we needed to build. And tech leads are expensive.

Instead we started with Software-as-a-Service (SaaS) products hosted in the cloud. Hubspot to store all leader and member signups. Eventbrite to sell tickets to meals. Stripe to take monthly subscription payments from leaders. Within a month we were running meals in Cardiff. 

We slowly worked out that these products talk to each other. Eventbrite tells Hubspot when people buy tickets or attend a meal. Stripe tells Hubspot when a leader sets up a payment. We started using workflows to automate things - update a leader’s status, send an email, notify us, add people to a list - whenever things happened in Eventbrite or Stripe. And we added more products - Sakari (SMS), Calendly (call booking), HelloSign (signatures), Donorbox (donations).

We still run on this SaaS technical architecture. Small pieces, loosely joined. Simple service design to keep it technically straightforward. Custom error messages to bring the inevitable exceptions to our (human) attention to fix manually. 

Again, there were trade-offs. Each product was easy-to-use for our users because they’d each been designed for a single purpose. The loose joins let us swap out Eventbrite for Tito in two days. But our service design was constrained by the capabilities of our tools and in some areas we learned we needed custom software. 

Worth it though. We saved more than £100k we would have spent on a tech lead.

Whole-team planning creates shared direction

I’ve seen what happens when you give individuals autonomy in teams without having a shared direction. Brilliant people go off in all directions. Wars break out. Money is wasted. It’s ugly and has scarred me for life.

At Local Welcome I created shared direction using a two-step process: 

  1. Phase planning. Every four months we gathered to plan the next four months. We did workshops including a retro, an appraisal of where we were, and an exercise to imagine our future over the next two years. Then we wrote our OKRs for the next four months as a team. We ended with writing a list of epics.

  2. Epic kickoffs. Each epic kickoff lasted two hours with the whole team. The first hour was show and tells so could all start from the same place. The second hour was us each answering five questions - what is this epic, why is it important, when is it done, what is included, what’s not included - and then discussing and arguing these into a single set of answers that defined the epic work.

Planning as a whole team brought things to my attention I’d have missed on my own. Even better, over time I watched people make smarter product decisions in their own post-its. That’s gold for any team.

Of course we had disagreements. When that happened it was me that made the final call when it came to product decisions. I found that having this whole process out in the open forced me to articulate my thinking in ways that made it easier for people to disagree-and-commit. It also meant they could hold me to account when my decision was wrong (which was often, and they did).

Yes, it took more time upfront to take a whole-team approach to planning. But what made our team more than the sum of its parts was that we didn’t just have individual autonomy - we had a shared direction too.

You’re gonna need a bigger goal

When I joined Local Welcome we wrote a two-year goal together. We did this without mentioning meals or refugees because I’d read somewhere that your goal shouldn’t tie you to an operating hypothesis.

We came up with “operate an impactful, inclusive ritual that is membership-funded”:

  • “Operate” because it wasn’t enough to just design a thing. 

  • “Impactful” because it had to improve people’s lives. 

  • “Inclusive” because we wanted diverse, powerful communities.

  • “Ritual” because attention, intention and repetition bind people. 

  • “Membership-funded” because we couldn’t rely on funders forever. 

For the first 18 months it felt like we didn’t need an abstract two-year goal to guide us. We were doing Local Welcome meals!

Until the Covid-19 pandemic happened and we had to stop doing meals. 

In the darkness we turned to our two year goal. We imagined new services. We kept asking - what is the ritual, how is this inclusive, why will people pay for it, what impact will it have, and how will our team operate it?

Our two year goal helped us pivot to Local Together and ADHD Together.

User research with real signups is my jam

At GDS I worked as a user researcher on GOV.UK Notify. Our users were government services. No recruitment agency could find participants and we couldn’t pay incentives. This was a big shock for the design agency researcher in me!

We improvised. When people signed up we offered a fair exchange - give us an hour and we’ll give you free early access. We got amazing research outcomes because our participants were already in the headspace of using the service. We didn’t have to manufacture hypothetical use cases. 

I brought this approach wholesale to Local Welcome.

When someone signed up we arranged a phone call. We asked how they found out about us, what they thought our service was, why they wanted to get involved, and what concerns they had. In return we explained things in detail, answered their questions, and gave them early access to our tickets. 

This helped us fix concerns and problems. It kept our team grounded because we all did calls. It built trust among our potential leaders.

When we launched Local Together and ADHD Together we started with Facebook ads and bare-bones propositions. We asked signups about their motivations, expectations and concerns. By the time we started running events our rituals were already designed in harmony with users’ needs.

Doing this kind of intercept research with signups is a powerful tool for developing new products. I’m amazed how little it gets talked about.

People respond best to real people

One of the first things I asked our designer to do at Local Welcome was to create a branded email template. Logo, brand, sent from “Local Welcome team", even some cute GIFs of puppies. 

We don’t use that template any more. Now we send plain text emails from our personal email addresses. Even for automated emails.

We learned that people (and spam filters) respond best to regular emails from regular people. They do things like open them, read them, and reply to them. And they just love to send angry emails when things go wrong.

Yes, it was hard to receive random angry emails. But it showed us where things were going wrong. And it gave us the chance to reverse the anger into loyalty with a proper apology. We said sorry, owned any pain we caused, avoided lame excuses, and explained what we’d do to resolve things. 

In January I started sending a monthly email to 150+ leaders to let them know what we were working on. It was a risk to expose them to our agile methods. But treat adults like adults and they respond like adults.

I know. Not possible at scale. But very useful when you’re starting out. 

Written culture makes things resilient

At Local Welcome we worked in a lean and agile way which meant lots of knowledge was in our heads. This was great for rapidly iterating a new service. But not so great when people started forgetting things, taking holidays, or leaving. Knowledge kept walking out the door.

Our antidote to knowledge loss was a written culture. We used Notion for this, which Ella - one of our trustees - describes like this:

“It's the beautiful love child of a website and a kanban board, mixed with the prettiest of all WYSIWYG blogging platforms you can imagine. With the efficiency of Google Docs. Basically, the Beyonce of software.”

We used Notion for three critical parts of our written culture:

  • Meeting notes. Every time we met as a team someone took notes in Notion. We did pretty much verbatim notes because it was easier than doing live-filtering. We created and followed an agenda. We captured actions as we went. This saved us a million times. 

  • Operational processes. We had a mix of automated processes and manual operations. We documented our manual operations so that we didn’t forget them and so other people could do them for us.

  • Epics. After phase planning we listed epics as cards. After kickoffs we added definitions to the cards. As we worked we stored notes inside cards and tracked progress on to do lists.

Listen to me talking about our written culture on the Cherryleaf podcast to learn more.

We were way more resilient with our strong written culture. It also made it easier to switch to remote working during the pandemic.

The runway won’t take care of itself

Local Welcome is not a big organisation. We had money in the bank and when it ran out we would cease to exist. Product growth costs money (hiring staff, opening groups) and makes money (tickets, donations). Understanding the impact of growth was my responsibility. 

We built an agile forecasting tool to help. A massive spreadsheet where:

  • Every column was a month stretching away off the right-hand side into the future. We looked two to three years ahead.

  • Every row was an expense row (staff costs, overheads, group costs) or an income row (funding, member income, donations).

  • Each expense/income row had a corresponding separate tab with a detailed model appropriate to the context (that fed the row).

  • The final row started with the cash in our bank and showed how that changed each month according to the modelled future.

This agile forecasting tool had several uses for us:

  • Showed when our cash ran out (cashflow runway) and our funding ran out (funding runway). These were not always the same.

  • Provided a tool for leadership to review actual against estimated spend each month to make sure our modelling wasn’t off track.

  • Let us model changes to staff, overheads, growth, tickets, group costs, donations etc to see their impact on our runway.

  • Helped us respond to the inevitable changes from operating in a lean and agile way by giving an always-up-to-date forecast.

  • Made it easier to communicate with the trustees who scrutinised our finances and understood the impact of our changing plans.

Our agile forecasting tool was put to the test when we came within six weeks of running out of money in March 2020. We saw this coming from September and stopped opening groups in December to give ourselves the runway we needed to land our next round of funding.

The one thing we stayed calm about during this stressful time was the accuracy of our agile forecasting tool!

Working with an ADHDer has changed me

Ben, who is the Local Welcome CEO and founder, has Attention Deficit Hyperactivity Disorder (ADHD). He was open about this and shared some of the positive and negative aspects of living with ADHD with me.

I’ve never knowingly worked with anyone with ADHD before. Although seeing as 5-8% of the population have ADHD I think it’s likely that I have.

Ben’s ADHD brain has lots of benefits. It’s faster than mine at connecting topics and seeing patterns stretching into the future. There are lots of  advantages to thinking in the way that Ben thinks.

But it causes some difficulties too. I worked with Ben to understand where his ADHD made things harder for him than for others. And we tried out ways of working to minimise the impact of some things:

  • People with ADHD often lose track of time. Our workplaces are often highly structured around time. We tried to find ways to nudge Ben to note the time when he’s in full flow, not hold him to unrealistic standards of promptness, or simply allow more time for discussions than we think we need because he needs more time.

  • People with ADHD can struggle to follow step-by-steps. Our workplaces are full of step-by-steps like agendas for meetings. We tried to build patterns into our Notion meetings where the agenda automatically formed the note headings. Our leadership team agenda led us heading by heading and it worked beautifully.

None of these difficulties stopped Ben doing a great job. They just meant that sometimes we needed to make adjustments to better include him.

Also, to be clear, working with Ben to make these tweaks didn’t make me special or heroic. In fact I felt the opposite. I felt embarrassed that I hadn’t questioned the ways we do these things in our workplaces beforehand.

Working like this taught me to pay attention to all the differences, for all the people, that make ways of working harder for some than for others.

Mistakes I’ve made at Local Welcome

Getting lost in our commitment to scale up

During the pandemic we had to stop doing our Local Welcome meals because they weren’t safe. We pivoted to two new services.

As part of our pivot we had one memorable team discussion where we were honest with each other about the problems of the meals model. The results were profound. We admitted that our meals were too complex logistically. That our groups cost so much that they took too long to generate income. And, hardest of all, that our meals had a problematic power dynamic by being about ‘helping refugees’.

My mistake was that I’d been so focused on meeting our commitments to scale up the meals model that I’d found it impossible to step back and see these problems. I need to find better ways to do this in the future.

Agreeing to do too many things at once

In November 2019 we were flying. We’d opened a new group each month since July. We were about to launch in Glasgow and Belfast. We were measuring the impact of our meals. I ran and analysed a huge survey with 500+ leaders and members and we presented our impact to funders to an event on 19 November. It went well.

But at the pub afterwards I had one drink and surprised myself by announcing that I had to take an unplanned week off. I went home exhausted and on the verge of burnout. I promised myself in 2015 I wouldn’t go through a burnout experience again.

My mistake was not saying no to our expansion plans once I realised they were too much work. We could have launched Glasgow and Belfast later. I let our organisational goals overwhelm my personal boundaries. 

Failing to hand tasks over quickly enough

We used a work pattern where when we were doing something for the first time - setting up meals in our tech, arranging leader availability across dates, forming partnerships with local refugee organisations - I’d learn by doing and then pass the task onto the team.

When done right this saved us time and got us good outcomes. But on each of the occasions above I didn’t make time to hand these tasks on. I ended up doing some of these for months when I should have been spending my time on other things.

My mistake, at first glance, was not being more ruthless about handing these tasks over quicker. But, going deeper, my mistake was assuming that I had to be the one that did these tasks in the first place.

Automating things before being ready

When I first got my hands on Hubspot I designed a user journey for people that signed up. It took people through a series of automated nudges and prompts to become a paying leader. It handed off user data neatly between Stripe and Hubspot. It catered to all sorts of edge cases.

Except it didn’t work. We didn’t know how to get people to be leaders. We didn’t know how to find leaders or what we expected a leader to do. 

My mistake was to get carried away with a technical architecture based on assumptions before I’d worked out the human-first solution. You’d have thought that I’d have avoided that one as a user-centred designer.

Repeating the same mistakes I’ve made before

The frustrating thing is that two of these are mistakes I’ve made before.

Agreeing to do too many things at once - also known as not saying no when I should say no - was the reason that I burned out when designing an online supermarket back in 2015. I’ve been much better at saying no since and it’s why I work a four day week. But it happened again.

Failing to hand tasks on to other people is something I’ve struggled with ever since I started managing people. The tendency to just do something myself rather than taking time to hand it over haunts me. 

My mistake here was assuming that just because I knew my previous mistakes I’d be able to avoid repeating them. This clearly wasn’t true. When I was under pressure I reverted to bad habits. 

What’s next for me?

I'm not sure yet!

I loved working at Local Welcome. It was the best job that I’ve ever had. A perfect combination of a great concept, a just cause, the freedom to try things out, a wonderful team, and (just enough) money in the bank.

It was my first full-time product role too. I learned about setting a product vision, prioritising work, running a high-performing team, fitting an idea to a market, managing budgets, procuring things, fulfilling legal responsibilities, and setting up a technical architecture. I even learned to go through a radical pivot.

I’m sad that I’m leaving but I’m peaceful about it. My role was always temporary, to get the team to a place where they fly away. I won’t pretend that there aren’t challenges ahead - developing new services is a risky business - but I’m proud of the work that we’ve done over the last two years.

I’m looking for a new product role from January. In a perfect world I’m looking for an interesting idea, that fits with my values, backed by a team of wonderful people, that we can develop together into a successful product for the people that use it and the organisation that runs it.

If you’ve got something then email me on myddelton@gmail.com :)

Building Local Welcome by tackling our riskiest assumptions

This is the written-up version of a talk I gave at Service Design in Government 2020. It’s the first time I’ve given a talk about being a product manager.


 
Layer 1.png
 

Local Welcome is a tiny startup charity. We run meals at the weekends where we bring together refugees and local people for two hours to cook and eat a meal. 

Local Welcome meals are not about feeding refugees, or doing things for refugees. There are many charities that do that. But that’s not us. We’re about creating a space where refugees and local people can come together as equal human beings. This means we are interested in reducing the power dynamics as much as possible.

That’s why we use food. Preparing and eating food together is a universal human experience. It reduces barriers to getting to know each other. It makes it easier when you don’t speak the same language. It reduces the pressure on people that feel shy.

Our meals are fun. They reduce loneliness, increase personal confidence, help people understand other cultures, change eating habits, strengthen social connections, and build much-needed social capital. 


 
Layer 2.png
 

But Local Welcome meals haven’t always been like this.

Local Welcome was founded in 2015 by Ben Pollard. He started by bringing Syrian refugees and people that wanted to help refugees together in Starbucks up and down the country. He realised that you can’t just bring people together and expect them to get on. You need something for people to do together.

We hit on using food to bring people together. It started with pizzas, moved on to pancakes, and ended up with whole meals. By prototyping, learning, and iterating we ended up at the two-hour meal that we love and are using today.

By the end of 2017 we knew we could run wonderful meals at a small scale.


 
Layer 3.png
 

In 2018 the National Lottery Community Fund gave us money to scale these meals across the whole of the UK.

The Lottery funded us to build a multidisciplinary team that included product, design, delivery, technology, operations and communications. They were interested in how approaches from the worlds of user-centred design and digital technology might work in small charities.

The Lottery were also interested in our self-funding model. Our proposal was to build Local Welcome so that it was funded by the people that came to our meals. Not by the refugees, because they have very little money, but by the local people. 

In November 2018 I joined Local Welcome as the product lead. Before I tell you about that there are two things I need to mention.


 
Layer 4.png
 

The first is about how I use the word ‘refugee’. I’ve used it a few times already.

When I say refugee I mean a person who has been forced to leave their country to escape war, persecution, or natural disaster. I think this is the common, everyday meaning of the word. When you read the word in a book, hear it in a film, or see it on the news this is what most people think it means.

But there is another definition. The Home Office uses the word ‘refugee’ to refer to someone that the UK Government agrees has legitimately been forced to leave their country. They call this ‘refugee status’.

This creates other statuses. When people first arrive they are ‘asylum seekers’ (or, better, ‘people seeking sanctuary’). If the Home Office decides you are not legitimate there are other terms. Like ‘failed asylum seeker’ or ‘destitute asylum seeker’.

I don’t care about the UK Government’s judgement. When I say ‘refugee’ I include all of these different people and statuses.


 
Layer 5.png
 

The other thing is to share a little bit about me. You should know where I’m coming from so you know whether to listen to me or not. There are three things to know.

First, I only became a product manager recently. Local Welcome is my first full-time product role. I’m still learning what it means. Take everything I say with a pinch of salt.

Secondly, I’ve worked in many ways. As product manager, user researcher, interaction designer, user experience designer, frontend developer and communications person. In the private sector for multinational corporations, public sector for GDS and the Home Office, and now in the charity sector. Waterfall, agile, agency, consultant and in-house. From being the only person in the cxpartners London office up to being one of tens of thousands at the Home Office. I say this to show that I am not wedded to any one viewpoint. They all have positives and negatives. None are right.

Thirdly, I am obsessed with making an impact. I have been frustrated with how little impact my work has had throughout my career. I started feeling this at agencies and I wrote lots about it. I moved in-house to see if being part of a multi-disciplinary team might help. I’ve moved to a tiny startup to answer the same question.


 
Layer 7.png
 

I’m going to start by going through how a Local Welcome meal works. There are three groups of people at our meals.

3 leaders. Leaders are local people who arrive early to set up the room, lead the food preparation and keep conversation flowing. They are like facilitators. They pay £5 per month and have done a DBS check and our safeguarding training. Each of them leads one meal a month.

9 members. Members are local people who get £5 tickets to come to the meal. They come as often or as little as they like. Some come once and decide it’s not for them. Others come again and again.

9 refugee guests. Guests also get tickets to come to the meal but the tickets are free. Guests also come as often or as little as they like. Guests and members are the same except for the payment.


 
Layer 9.png
 

There are three tables set up at the meal. Each table is set up to make a different recipe. For example, chickpea salad, potato rosti and tabbuleh. All the food and equipment needed to make the recipe is laid out on the tables.

Each table has a leader who guides the group through a seven step recipe. Each step has a question to get the conversation going. The questions are designed to be safe.

Each table has three cooking pairs. Each cooking pair is a local person and a refugee guest. They have their own cooking station - basically a chopping board and knife - and the pair works together on each recipe step. For example, chop an onion.

After about 45 minutes the three tables finish making their recipes.


 
Layer 10.png
 

When the recipes are made we push the tables together, lay out the food, and eat the whole meal as one big group. This is our group eating in Derby.

After we finish eating we wash up and pack away together. It’s during this last 30 minutes that the best conversations happen. People feel at ease.

This whole thing is like a technique called 1-2-4-All from Liberating Structures:

  • Arrive on your own (1)

  • Pair with someone to make food (2)

  • Get to know your table as you make food (7) 

  • Eat and tidy up as a big group (all). 

This means that people, even shy people, feel safe when meeting new people and feel OK about joining the bigger group. That’s what makes our meals wonderful.


 
Layer 11.png
 

In January 2019 we knew how to run wonderful meals on a small scale. Our task was to scale up so that there were enough meals across the UK to get us to self-funding.

The big question was how are we going to do this?


 
Layer 12.png
 

We had a hypothesis. This was the basis of our Lottery proposal in 2018. 

The hypothesis was that we can get to self-funding. It’ll take 100 groups, which means 100 meals every weekend. Each group will have 100 members and all of them will pay £5 per month. That means £50,000 per month to pay for our team and operating costs. And the whole thing will take us two years.

This was a plausible hypothesis. We made financial projections and growth forecasts. There were spreadsheets and milestones. 

It was also a guess. You can tell because it’s full of suspiciously round numbers. It’s OK that it was a guess. All business plans are guesses. All guesses contain assumptions. Some assumptions are riskier than others.

We decided to build Local Welcome by focusing on the riskiest assumptions first.


 
 

These were our riskiest assumptions in January 2019. We assumed that we could do all of these things as part of getting to self-funding. If any one wasn’t true then we didn’t have an operating model. 

We wanted to face the riskiest assumptions early so we could know sooner rather than later whether we had a shot at getting to self-funding.

I’m going to take you through how we tackled these risky assumptions.


 
Layer 14.png
 

In January 2019 we set out to start groups in cities we don’t live in.

We set four February launch dates in Cardiff and Birmingham. None of us had ever lived there. We did some things to make it easier for us to launch:

  • Hired community halls for two dates in Cardiff and two dates in Birmingham (rather than trying to find a forever venue).

  • Went up on the train, carried the equipment, bought the food, and led the meals (rather than looking for local leaders). 

  • Partnered with Migrant Help to find refugee guests staying in nearby hostels (rather than connecting with wider communities).

The big thing we were testing was whether we could find local people, in new cities, who were interested enough to come to our meals.


 
Layer 15.png
 

We ran an experiment using Facebook adverts. We showed three adverts to people who lived within 5 miles of the meals. Each advert linked through to an Eventbrite page which had 12 free tickets to the meal. 

It worked! The Facebook adverts worked so well that they are the same adverts we use today. We’ve found more than 3,500 people like this.

By the end of February we knew we could start groups in cities we don’t live in. We knew how to connect with local demand.


 
Layer 16.png
 

In March 2019 we set out to recruit capable paying local leaders. Up to then we had been leading meals ourselves.

We needed capable local leaders because our team of six couldn’t keep leading meals forever. We needed local leaders to pay or we wouldn’t have a financial model.

We tried asking the 48 people from the Cardiff and Birmingham meals in February to be leaders. We did a clumsy pitch but only two people signed up. This 4% conversion rate wasn’t good enough: we can’t be running four meals to find two leaders!

There were two problems with our clumsy pitch. People were not expecting to be asked and they didn’t know what being a leader involved.


 
Layer 17.png
 

We ran an experiment when we launched in Thornton Heath in April. We intercepted people after they clicked on our Facebook adverts and did three things:

  1. Asked whether people were leadership or membership material. Amazingly, 20% of people said they were up for being leaders.

  2. Called them to explain Local Welcome and answer questions. This built trust, helped us understand motivations, and built their commitment to our idea.

  3. Invited only these potential leaders to the first two meals in Thornton Heath. We left the members on the shelf until a later date when we had found leaders.

This worked! 10 of the 20 people from the first two meals in Thornton Heath signed up and paid to be leaders. This 50% conversion rate was more like it. Within weeks these leaders were leading meals themselves.

By the end of April we knew we could recruit capable paying local leaders


 
Layer 18.png
 

In May 2019 we set out to get local people to pay £5 per meal. Up to then we had been doing free tickets to meals.  

This felt like our riskiest assumption. When I talked to people in charities they would smile and edge away as they realised this was the foundation of our operating model.

There are broadly two mental models people have for charitable giving:

  • Donating. For example, you set up a £10 direct debit to Oxfam and this goes out every month. You are giving money.

  • Volunteering. For example, you go to a food bank one evening a month to pack and distribute food. You are giving your time.

We were asking people to give both money and time. This doesn’t fit into either of these mental models. And I’ve learned to be sceptical of any innovation that messes too much with pre-existing mental models.


 
Layer 19.png
 

We ran an experiment in May in Cardiff, Birmingham, and Thornton Heath. We turned on paid tickets in Eventbrite. It took less than five minutes.

It worked. People bought tickets. Every meal since has been all paid tickets. We’ve sold more than 11 of 12 tickets as a rolling average.

We never asked anyone whether they would pay. Or how much they would pay. I’ve done this research before, back in agencies, and got burned. When it comes to price, the gap between what people say in research and what they do in real life is huge.

Being burned like this convinced me that the only way to find out about price is to offer something valuable and ask people to pay for it with their own money. We could have prototyped and tested things in the lab but I insisted that we build a real service from day one so we could get to our riskiest assumption quickly.

By the end of May we knew we could get local people to pay £5 per meal. There was huge demand we could tap into wherever we went.


 
Layer 20.png
 

In June 2019 we had to stop and remove our team from running meals. We hadn’t realised this was a risky assumption until we found ourselves stuck in June.

In June we ran two meals in each of Cardiff, Birmingham and Thornton Heath. Local leaders were leading the meals but we still had to go along ourselves. We were the only ones who could open the venue (alarm codes), do attendance (lists of names), and answer difficult questions.

With a team of only six people we couldn’t add meals to existing groups, let alone open new ones. I was starting to hate Sundays too.


 
Layer 21.png
 

We ran multiple experiments. It took ages. It was slow and painful.

We tried giving instructions to leaders via the web because it was easy to maintain. Leaders didn’t want to use their smartphones at the table though. Food hygiene was a problem as phones aren’t sanitary. Social perception was a problem because it felt like leaders were looking at Instagram. And we were attracting a diverse group of leaders who didn’t all have smartphones or feel confident using them.

We tried giving the same instructions on paper. We designed plastic A4 sheets and clipped them into pink ring binders. This worked beautifully. Leaders took the sheet they needed and put it back afterwards. They cleaned the sheets before and after use. They felt socially present. But it didn’t solve the problem of secret information. We can’t have burglar alarms and sensitive names floating around on bits of paper.

We tried creating a ‘primary leader’ role. One of the leaders had a briefing with us to get the secret information like burglar alarms and lists of attendees. They were then responsible for keeping that information safe. Finally, at the end of July, we stopped going to Cardiff, Birmingham and Thornton Heath. We opened Derby in August. 

By the end of August we knew we could remove our team from running meals. We went on to launch new groups in Liverpool (September), Wakefield (October), Glasgow (November) and Belfast (December). 


 
Layer 22.png
 

In September 2019 we set out to prove our meals have meaningful impacts. We knew anecdotally that our meals had good outcomes but we didn’t have any data.

People in the charity sector were appalled that we’d been running meals for so long before looking at outcomes. Outcomes are how the sector measures value. They underpin funding from trusts and foundations.

There were two reasons why we didn’t look at outcomes earlier:

  • One reason was methodological. Using agile and lean methods mean we try things, learn from what happens, and make changes to our model. Our model changed loads between January and September. I didn’t want to spend months measuring outcomes that came from an outdated model.

  • The other reason was contextual. Our outcomes build over time. You don’t come to a meal for two hours and instantly feel less lonely or more confident. It takes coming back again and again. We needed to run for a while to see outcomes.

By September we had six groups running on a stable model. Ready for outcomes.


 
Layer 23.png
 

We ran an experiment. We set a date in November, booked a room, and invited powerful funders to an event to unveil our outcomes.

However, in September we hadn’t done any of this work yet. We spent the next two months running around and settled on two things:

  • The Social Impact Consultancy did some independent research into the impact of meals on leaders, members and guests. They observed and did interviews. They came back with an impartial third party report into the impact of our meals.

  • I leaned on my researcher past to do a survey of leaders and members. We got more than a 50% response rate which still amazes me. We asked questions about demographics, motivations, and outcomes they’d experienced over time. 

We did this on top of opening a new group each month. It broke me. After the event I took an unscheduled week off and did nothing. I didn’t recover until January. I told myself ages ago to avoid burning out and this was a reminder of why that matters.

At least we managed to prove our meals have meaningful impacts. I’m going to share the three impacts that mean the most to me. 


 
Layer 24.png
 

This is a refugee guest talking. They’re saying that for two hours they were able to stop thinking about the things that usually preoccupy them.

We were expecting this outcome. Our meals are designed to get people to focus on a task, and on interacting with others, and this ends up feeling like a flow state. The world ebbs away for two hours.

It was still important for our team to see evidence of this outcome.


 
Layer 25.png
 

This is one of our local members. They met a refugee guest at a meal, realised this person needed something, met up outside of the meal, and then became friends.

We had hoped for this outcome. It’s why Local Welcome meals are important. What starts on the table ends up going beyond the table.

It was massive for us to see evidence of this outcome.


 
Layer 26.png
 

This is one of our local leaders. They’re saying that being a leader made them more confident. They applied for, and got, a promotion that had a material impact on them.

We hadn’t expected this outcome. I thought that the 20% of people who said they were up for being a leader were already leaders. Maybe at work. Maybe in a youth group or scout troop. Maybe in a large family. 

Yes, maybe half are leaders already. But the other half are not leaders, or don’t see themselves as leaders. Local Welcome puts people in the lead and this carries over into their everyday lives. I said I’m obsessed with having an impact. This is the first time in my career I’ve felt it’s working.


There’s something else here too. We saw the same outcomes - decreased loneliness, better understanding of others, increased confidence, stronger social connections and better social capital, changed eating habits - across everyone at our meals.

I said we’re not doing things for refugees. That’s easy to say. Our impact work showed that Local Welcome meals have the same impacts on everyone that comes to them. The meals are not just for refugees, they’re for everyone.

By the end of November we could prove our meals have meaningful impacts


 
Layer 27.png
 

In January 2020 we set out to find refugees to come to our meals. But how have we been running for a year if we can’t find refugee guests?

We used a hack in 2019. There are eight initial accommodation centres in the UK for people claiming asylum. People stay for two months before being ‘dispersed’ around the UK. Our first eight groups opened next to these hostels and we partnered with Migrant Help to find refugee guests.

This was convenient for us. It let us focus our attention on starting groups, finding leaders, getting members to pay and proving impact. 

It was also problematic. These refugees were a subset of the wider population. Their English was poorer because they had just arrived. They only stayed for two months so longer-term connections were hard. And we were picking refugee guests up from hostels which felt infantilising. It wasn’t reducing the power dynamics at our meals.

Since January our meals have been open to all refugees in our cities. They get their own tickets. They turn up themselves. Just like our members. It’s much more equal.

But it’s also a lot harder to make it work.


 
Layer 28.png
 

Our first experiments focused on infrastructure for guest tickets:

  • We tried using Eventbrite and email because we use those things for members. This approach failed. Eventbrite is hard to use even if English is your first language. Lots of refugees don’t have internet access, let alone email addresses.

  • We tried using text messages. This worked well. Most refugees have mobiles and can get texts even with no credit. If they don’t have a phone a friend or caseworker can get their ticket for them and give them the number.

Our next experiments were about increasing awareness among refugees:

  • We tried a ground-up approach to get in touch with organisations working with refugees. We asked local leaders to introduce us to people and snowballed out. We’ve been mapping all the services in these cities and asking them for help.

  • We tried sending local leaders to drop-ins where refugees congregate for legal advice or social activities. Our leaders participate in the session, talk about Local Welcome, and invite refugees to come along. This works well.

But it’s March 2020 and we still don’t know if we can find refugees to come to our meals. Yes, we’re issuing more guest tickets, but it’s a lot of manual work and drop-out rates are high. It’s our riskiest assumption. If we can’t work out how to do this then our operating model is sunk.


 
Layer 29.png
 

Which means we’re not ready to scale to 100 groups with the same team.

We opened eight groups in 2019. But that wasn’t about scaling up, it was more about learning whether we have a viable operating model. Each group was an experiment.  Soon we’re going to see whether we can operate more groups with the same team.


 
Layer 30.png
 

People ask me if it is even possible to scale to 100 groups with the same team. The truth is that I don’t know.

On my good days it seems like a clear path. We automate loads. We devolve more responsibility to leaders. We get word-of-mouth awareness going. We remove the problems that create support tickets. 

On my bad days it seems impossible. We’ll never find enough venues. We’ll never get the guest turnout. Our team will never be able to operate ten times as many groups without growing.

I just don’t know. But looking back over the last 12 months gives me hope.


 
 

A year ago these things were all risky assumptions. We didn’t know how to do any of them. At some point, each of these things has kept me awake at night. All of them seemed impossible at times.

But our tiny team has worked through these risky assumptions, one painful experiment at a time, and we’ve learned how to do new things.


 
Layer 32.png
 

We’ve learned is that our original hypothesis wasn’t right. So we’ve been updating it.

We can still get to self-funding because nothing has ruled it out yet. It’ll take 80 groups rather than 100 groups (there is maths but I’ll spare you). Each group will have 30 leaders (who pay monthly subscriptions) and 48 members (who pay for meal tickets). They’ll have to pay £8, not £5, because we learned how much it costs us to start a new group. That gives us £49,920 per month to pay for our team and operating costs. But it’ll take us three years which is a big deal because our Lottery money runs out this summer. We have been out trying to raise more money.

This revised hypothesis is a guess. An informed guess because we’ve learned things. But still a guess. And that’s still OK.


 
Layer 33.png
 

It means we have a new set of risky assumptions.

We don’t know how to do any of these things yet. We have plans. But we don’t know.

This is what we’re working on for the next 18 months. Because, at Local Welcome, we structure work by tackling our riskiest assumptions.


 
Layer 34.png
 

Before I finish I want to share five things that I’ve learned in the last year.


 
Layer 35.png
 

OMG. I’ve learned that everyone has an opinion about how I do my job! Why did no one tell me this is what being a product manager means?

My team has opinions. Our leaders, members and guests have opinions. My mum has opinions. Anyone I meet at a party, or at a conference, is telling me their opinions within two minutes. People even have opinions before coming to a meal - I had a 14 paragraph email from someone who took great care in tearing down every aspect of our proposition despite never having been to a meal.

That’s OK. Feedback is a gift. I smile, I nod, and I listen. I’ve learned a ton of things from people’s opinions. Things that have changed our direction.

But it’s also emotionally hard. Like on a Tuesday afternoon, when I’ve spent two days dealing with a customer service disaster at the weekend, and I get a 14 paragraph email from a stranger telling me the things I’m doing wrong. It makes me want to cry.

I have a newfound respect and empathy for product managers. Especially the ones I’ve worked with. Because I definitely had opinions about how they did their jobs.


 
Layer 36.png
 

I’ve learned that putting out fires is a valid design approach. When doing experiments we’re creating a bare-bones service that just about works. Every part of the service is ‘good enough’ and we come back and fix bits that are broken (e.g. putting out fires).

What I had never realised is that you rarely come back and fix the parts that are not broken. Things that work stay as they are. So we’re full of bare-bones ‘good enough’ design decisions that I find horrifying and embarrassing: 

  • The agency designer in me is horrified because we’re not thinking it all through upfront, documenting everything, making it feel consistent, or having a solid rationale for each element. That’s what I used to sell.

  • The in-house designer in me is horrified because I got so used to agile teams failing to come back and iterate that I ended up doing upfront design work as a rational defensive measure.

My perspective has shifted now that I’m making these decisions. We have limited time and money and we need to spend it on what’s most important. That is usually moving to the next risky assumption rather than assuaging the guilt of all my inner-designers.

So I tell myself it’s OK that lots of things are a little bit broken most of the time.


 
Layer 37.png
 

I’ve learned not to automate things until I know they work. This was painful because I’ve spent years telling teams not to build technical solutions until they understand how people will use them. 

Then when I joined Local Welcome I spent weeks designing and building a powerful, elegant, automated system to sign people up to be leaders. Nudges, emails, calls-to-action, flows. It was beautiful. It didn’t work. Not a single person signed up.

It didn’t work because I didn’t know how to sign people up to be leaders. To find out I called people up and asked them to be leaders. Over time I learned how to ask the question in an email. And later still I was able to automate the emails. Once I knew how it worked, I could automate it.

That’s our pattern now. When we face an unknown we put a human on it until they figure out how to do it. Then we work out how to automate it.


 
Layer 38.png
 

I’ve learned how powerful experiments are. We tackled our riskiest assumptions using experiments. We opened new groups with different start conditions. We tried things in one group before another. We sent different things to different people. We failed lots.

I’ve had a long-running suspicion of the word ‘experiment’ though. So let’s be clear.

By ‘experiment’ I just mean that we changed something, paid attention to what happened, and learned stuff. When it came to learning we used intuition and gut feel as much as hard data. I’m OK with this, because when we’re looking at our riskiest assumptions then our experiments have big, obvious, pass/fail type answers anyway.

By ‘experiment’ I don’t mean that we set up rigorous tests where we isolated single variables and used statistically significant sample sizes to tell us the objective truth about the world. Maybe we’ll run those kinds of experiments when we’re operating at large scale. Maybe not.

I’m not mad about words like ‘experiments’, ‘hypotheses’ and ‘assumptions’ either. These are borrowed from science and they can encourage the macho unthinking bullshit of scientism. We’ve all seen people - often overconfident men - who treat numbers-from-any-source as more important than stories, experience and hunches.

But experiments are powerful. As long as we remember that we’re not doing science.


 
Layer 39.png
 

The final thing I’ve learned is something I’ve been learning for years. When it comes to multidisciplinary teams it’s the shared goal that matters more than anything. That’s what allows us to be more than the sum of our parts.

I’m going to get to this in a roundabout way.


 
Layer 40.png
 

This is an album called Screamadelica by Primal Scream which meant a huge amount to me as a teenager in the mid-90s. My favourite track on it was Come Together. This was produced by Andrew Weatherall (who died recently, much too young) using a sample of a young Jesse Jackson speaking at WattStax in 1965 to tie it together:

Today on this program you will hear gospel,
And rhythm and blues, and jazz
All those are just labels
We know that music is music.

This sample had cosmic significance for 16-year-old me. The words ring in my head. They forever changed how I listened to music, thought about music, made music.

I’ve realised, recently, that they still have cosmic significance for 42-year-old me.

When people talk about agile, systems thinking, user-centred design, lean, extreme programming - my mind says ‘all those are just labels’. When people talk about product management, service design, interaction design, information architecture, user experience design, user research, content design - my mind says ‘all those are just labels’ too.

Labels can help us learn our craft, talk to each other clearly, and save time by using a specialised vocabulary. But labels can also divide us if they become part of our identity. They end up creating us-and-them groups. I know because I was part of this at GDS in the user research team. It happens.

I think we talk too much about labels and not enough about our teams’ shared goals. 

I learned how important shared goals were when I was running discoveries at GDS. We went round in circles trying to find out everything about everything. Eventually someone sat me down and said your goal is to decide whether to pursue this opportunity or not. Overnight we all started pulling as one team in the same direction.

You already know how important shared goals are because I’ll bet that you’ve worked on teams that don’t have them. Your team is full of lovely, bright, capable people but you’re all going in different directions and it ends up being a horrible nightmare. Multidisciplinary teams need shared goals to work well together.

It’s why I don’t hold with “start with user needs” much any more. Teams start with a shared goal. Maybe that goal comes from what you know about people. Maybe it comes from a burning desire in your heart. Or a politician elected on policy intents. Or even just a plain old profit motive. Whatever. We start with the shared goal.


 
Layer 41.png
 

This is our shared goal at Local Welcome. In two years we are trying to operate an impactful, inclusive ritual that is membership-funded.

We wrote this goal together. We revise it when we need to. We use it as the basis for all our roadmaps. We refer to it all the time. This is our goal.

I talked about our hypothesis. It’s meaningless to talk about our hypothesis without knowing our shared goal. Our hypothesis is one of many (many) hypotheses to achieve our goal to operate an impactful, inclusive, ritual that is membership-funded.

This whole talk has been about tackling our riskiest assumptions. The risky assumptions come from the hypothesis which comes from the shared goal. Our whole team is able to trace their work back to our shared goal at any time. It’s powerful.


 
Layer 40.png
 

Looping back to Primal Scream and this labels thing.

This is why I love it when our team questions the ways we work. When they say let’s stop doing sprints. Or let’s change how to do retros. Or maybe this whole bit of work doesn’t need any user research. They’re saying…we know that these are just labels.

I love it because it shows our team isn’t focused on the labels. Instead they’re thinking about our shared goal. They’re saying…we know that music is music.

Come together as one.


 
Layer 1.png
 

OK, enough, let’s wrap this up.

Building Local Welcome by tackling our risky assumptions has been scary. Every day we come into work facing into the abyss. Thinking if this thing doesn’t work then we don’t have an operating model.

There are other, less scary, ways to work. I’ve been on projects where we didn’t face our riskiest assumptions until the end. We spent most of the time doing fascinating, interesting and compelling design work. Towards the end we tried to retrofit reality to our work. Always without success.

I’m convinced that facing our riskiest assumptions has been a good way to build Local Welcome. I wonder if that will change as our service matures? I guess we’ll find out.


 
 

I’m going to end with a poem.

It’s from a book which is called The Poetry Pharmacy. It’s a peaceful, healing book. Just before I started at Local Welcome I took this off a bookshelf in Bristol and it fell open on this poem.

I’m open to weird signs from the universe these days. So I decided there and then that this poem was going to sum up my Local Welcome experience. It has.

Here it is:

Come to the edge.
We might fall.
Come to the edge.
It’s too high!
COME TO THE EDGE!
And they came
And she pushed
And they flew.

Christopher Logue

Thank you.

Let me know what you think on @myddelton. Local Welcome is also Ben Pollard, Claire Brown, Celia Mellow, Andrew Chaplin and Efe Harut. We did this together.

Learning to scale up Local Welcome

Local Welcome started in 2015. We were trying to bring refugees and local people together to get to know each other. After several false starts we hit on the idea of meals where everyone cooks and eats together.

The initial work was small-scale. One-off meals in random locations. Mad dashes to get people together. Learning to run great meals.

In 2018 we got funding from the The National Lottery Community Fund to expand our meals. This money was to experiment with using human-centred design, a multi-disciplinary team, and lean and agile methods to scale up across the UK.

In February 2019 we opened our first Local Welcome group in Cardiff. We got some things right, but we got lots of things wrong. Through 2019 we opened groups in Birmingham, Thornton Heath, Derby, Liverpool, Wakefield, Glasgow, and Belfast. Each time we learned a little more.

Now, 12 months on, we have learned three important things about scaling up our approach to Local Welcome. They are about:

  1. Launching new groups in new locations

  2. Planning our work using lean and agile methods

  3. Building internal systems to support our work

We have more to learn. We’ll make more mistakes. But the Lottery money gave us time to learn how to systematise and scale our approach. We hope that sharing what we’ve learned might be useful.

1. Launching new groups in new locations

We are now confident that we know how to launch a Local Welcome group in a new location. We did this 8 times in 2019. None of the locations were in places we knew well. This was deliberate! 

The launch process for a Local Welcome group is:

  • Identify a suitable location

  • Find an appropriate venue

  • Run Facebook ads to generate interest

  • Set up partnerships to find refugee guests

  • Run meals to recruit diverse and capable leaders

  • Turn out paying members to the meals

  • Hand over on-the-ground work to leaders

  • Grow the number of meals until we’re running weekly.

These steps look obvious with hindsight! Trust me they were hard-won. Each involved a huge amount of experimentation, failure, learning, and - eventually - finding something that worked well enough to use.

The most important things we learned was how much it costs, how much effort it requires, and how long it takes. This means we now have more realistic plans for how we’re going to expand to 80 groups.

The hardest thing we learned was how to stop sending one of our team to each meal. It took months to get all the tacit knowledge that was in our heads and communicate this properly to local leaders.

Now we’re ready to launch lots more groups. We’re also ready for continuous improvement because we know which parts of the launch process aren’t working perfectly and are itching to fix them.

2. Planning our work using lean and agile methods

The Lottery money, and the flexible conditions of how it was released to us, helped us learn to plan our work using lean and agile methods. 

‘Lean’ and ‘agile’ are horrible jargon. I thought about not using these words. But part of the Lottery funding was about experimenting with lean and agile methods in the charity sector. So here is what they mean to us:

  • ‘Lean’ is a way to organise work to minimise waste and maximise productivity. We do this by giving every member of the team the power to make improvements to the way things operate. For these improvements to be helpful, everyone on the team needs to understand the way the whole organisation operates.

  • ‘Agile’ is a way to organise work to do a tiny bit, see what happens, learn from it, and then go back and change it for the better. We focus on making the most important things good enough (but not perfect). For this to work, everyone needs to know what’s most important, what’s not working, and what’s ‘good enough’.

One part of working like this is that our whole team makes plans together. We all need to know where Local Welcome is going and how we’re trying to get there. Otherwise we can’t make good decisions on our own. At the end of every four month phase we do these things together:

  • Phase retrospective (a ‘retro’) - reflect on what we’ve done, celebrate the successes, work out what’s been going wrong

  • Roadmapping - re-plan the next two years from our current position based on what we know (based on a Jamie Arnold post)

  • Objectives and key results (‘OKRs’) - set clear priorities and measurable indicators for the first 4 months of the roadmap

  • Phase kickoff - discuss and prioritise the work we’ll do to meet these objectives (based on Pete Herlihy’s inception workshop

Another part of working like this is making sure we encourage, receive and act on feedback from our leaders, members, guests, and partners. Otherwise we won’t know what’s not working. We do:

  • User interviews with leaders before they sign up

  • Debriefs with our leaders after every meal

  • Automated feedback surveys for members and guests

  • Regular phone check-ins with partners

  • In-person reports from our team members

  • Periodic depth research and analysis into our impacts.

The most important thing we’ve learned to do is a weekly debrief on a Monday morning for the whole team. We go through the feedback from the weekend’s meals to analyse feedback and agree changes together.

The hardest thing we’ve learned about lean and agile methods is how to measure impact. Lots of Local Welcome outcomes are slippery to measure. We didn’t start measuring until we had 6 groups because we wanted enough valid data. This left little time to measure our impact before we needed to write new funding applications. Stressful.

We are a small team. Using lean and agile methods helps us plan work together and respond to feedback as a team. We think it pays off when our team performs as more than the sum of its parts.

3. Building internal systems to support our work

Finally, we learned how to create, document and operate complex internal systems. This will allow us to scale up the number of groups we run without scaling up the team at the same rate.

One of my favourite quotes is from a systems thinker called John Gall:

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
John Gall, “Gall’s Law”

At Local Welcome, we started 2019 by trying to design complex systems from scratch. Gall’s Law was right. This did not work:

  • We made an elegant automated workflow to recruit leaders. But it recruited no leaders because it didn’t speak to their needs at all.

  • We started by asking leaders to recruit 7 friends as members. But it turned out that almost no-one had 7 friends they could co-opt.

  • We launched refugee tickets using email addresses for booking. But refugees rarely have the internet, let alone email addresses.

We learned from these failures. 

Now we start with the simplest system that can be operated by one of the team. This forces that person to understand the people that use it by coming into direct contact with other humans and the context of use.

When the simple system is working well - in the sense of achieving its goals, not in the sense of being highly efficient - we document it in Notion. (Notion is incredible for a team who are learning as they go). 

When it’s documented in Notion it means that any of us can do it. This is great for when we go on holiday or are off sick. It’s also great for thinking about which things we can automate to become more efficient. Eventually we automate most things. Otherwise we can’t scale up.

After doing this over and over again, Local Welcome has now evolved a set of simple systems into a complex system that works. We operate:

  • Weekly tasks centred on running meals, monthly processes tied to arranging meals, and ad-hoc checklists for launching new groups 

  • User journeys that take place over several months involving contact with multiple members of our team

  • Automated tasks in Hubspot and Zapier that now do in seconds what used to take us hours as humans

  • Manual processes documented in Notion

  • Dashboards and alerts to keep us informed about what matters.

The Lottery money enabled this because it understood that we couldn’t design this complex system upfront. Instead, we had to start from simple systems and then evolve them into a complex system.

We are now ready to scale up to 80 groups

Our funding from the National Lottery Community Fund helped us systematise our approach to Local Welcome in three big ways:

  1. We know how to reliably launch groups anywhere in the UK 

  2. We’re running a team that is more than the sum of its parts

  3. We’re operating a complex system that changes as we learn.

It took us all of 2019 (and a little bit of 2020) to learn these three things. It’s only the start of our journey if we’re going to grow to 80 groups and get to self-funding by the end of 2021. There are huge challenges ahead.

We wouldn’t be here without the way that the Lottery funded us. Working with agile and lean methods doesn’t lend itself to traditional funding models based on known outcomes that are fixed to points in time. It took a lot of bravery for the Lottery to fund us without those things. 

We are thankful. And so are our leaders, members, and refugee guests.

Say hello on @myddelton. Posted originally on the Local Welcome blog. This post started life as an answer to one of five questions posed to us by Cassie Robinson. We’ve been meaning to share more about what we’ve learned over the last 18 months. These questions helped with that.