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 :)