Distributed Learning: Design for Connectivity, Not Proximity

Designing for Connectivity, Not Proximity

Your workforce went distributed years ago, but did your learning and development? L&D experts Andy Lancaster and Tom McDowall unpack what actually works to strengthen learning and build connection.

Most businesses didn’t choose to be distributed. 

Their workforce did it for them: remote hires, multi-site operations, shift patterns, field teams who were never going to sit in a training room in the first place. 

And most of us responded the same way everyone else did. 

We took what worked in a room and tried to ship it out.

But with 70% of multinational companies relying on cross-cultural teams, a figure set to reach 85% by late 2026, learning and development teams now more than ever need to prioritise connection over physical presence.

Andy Lancaster joined Tom McDowall for the first episode of BuildEmpire’s webinar series in partnership with Totara in September, split into why we’re focused on the wrong starting point, and how to fix it.

Their throughline: this is about designing not for proximity, but for connectivity.

That one distinction does more work than it sounds like it should.

Here’s what it means in practice, and what it should change about how you build learning for a team that isn’t in the room.

Learning Ops Webinar in Partnership with Totara | Guest Andy Lancaster

⏰ TL;DR

Stop designing learning around getting people into a room and start designing it around connecting them wherever they are. Replace the informal support, coaching and problem-solving that used to happen by accident when teams shared a space, because none of it survives going remote on its own. And measure what you build against organisational outcomes, not learning activity, or you’ll never be able to prove any of it worked.

Keep reading to learn:

  • Why most learning infrastructure still gets built for proximity, not connectivity
  • What disappears the moment a team goes distributed, and why nobody budgets to replace it
  • Why you should design for the hardest-to-reach person, not the average one
  • Why friction is a design failure, not a technology problem
  • How to get social learning working without it fizzling out
  • The metric most L&D teams still get wrong

How to design for connectivity

Andy’s spent over thirty-five years in L&D, including running learning for people in substance misuse rehab centres, a housing association reaching the Isles of Scilly by helicopter, and most recently 160,000 dispersed members at the CIPD. 

His argument for quality learning is that it is about  “designing not for proximity, but for connectivity.”

That one distinction does more work than it sounds like it should. 

Here’s what it means in practice, and what it should change about how you build learning for a team that isn’t in the room.

The room was never the point

Most learning infrastructure is still built for proximity. 

Get people into a venue, run something synchronous, call it training. It’s a model nobody’s had much reason to question, not because it’s been proven to work, but because it’s familiar. 

Even when everyone’s on the same site, that assumption holds up less than people think, and it falls apart completely the moment they’re not. Most organisations are only now finding out how hard that redesign actually is.

Andy put it plainly: “This is about designing not for proximity, but for connectivity.” Distribution isn’t only about time zones, he said. It’s locations, access, and a whole range of factors that proximity-first design never had to account for.

The bigger problem is that most of what still gets built for distributed teams is event-driven, because events are what we know how to control.

 “We’ve historically been focusing on events, not access,” Andy said, and that’s control dressed up as good practice. Events are also expensive, and in the current market, cost matters whether we like it or not.

It’s worth asking honestly why events still feel essential. 

Working with a large European client, Tom ran internal surveys asking exactly that. 

The result? “There was a really strongly held perception that pretty much always training’s better when we all get together.” 

But when his team dug past the preference and asked what it actually did for performance, “no one could ever really clearly articulate how it was helping them be better at their jobs.” 

People like being around colleagues. 

With roughly 62% of global employees unengaged, regular team-building shifts can boost engagement by up to 30% and reduce absenteeism by 41%. That’s a genuine business case.

 It’s just not a learning outcome, and treating it as one is how L&D budgets get spent on the wrong thing.

The practical filter Andy suggested: ask when you genuinely need to be together, not whether you’d prefer it. 

Some things, particularly emotional or practice-based skills, benefit from real synchronous time. But most don’t.

Unbudgeted losses when going distributed

Going distributed doesn’t just remove a room. 

It removes everything that used to happen inside it by accident. 

Roughly 63% of off-site staff report feeling under-equipped for their roles, while 36% struggle to navigate digital onboarding altogether—a direct consequence of losing those organic corridor chats where tacit knowledge used to be shared.

Mentoring junior staff and passing on subtle cultural knowledge takes much longer.

“This is what happens during the coffee time,” Andy said. “Invariably, things are solved.” 

On one management development programme he ran, so much problem-solving was happening over lunch that the team deliberately extended it from sixty to ninety minutes, because the coffee break was doing more for performance than some of the formal sessions.

None of that gets logged anywhere as an L&D intervention, which is exactly why nobody plans to replace it when a team goes remote. 

Andy’s fix is to treat it as a design brief: audit what actually happens around the edges of an event, then rebuild it deliberately. 

Watching an expert at work becomes a digital lunch-and-learn. The overheard advice and quick corridor questions become a forum thread or a wiki people are actively pointed towards, not left to discover.

This matters because distribution doesn’t just change where people work. It exposes who was already being underserved. 

The people furthest from the centre were always the ones most likely to miss out on informal support, long before anyone went remote. Distribution just makes the gap visible.

Design for the edges, not the middle

Andy trained originally in furniture and silversmith design, and the comparison has stuck with him ever since: “You never design a chair for the average person… you have to think about the actual fit for everyone.” 

Applied to learning infrastructure, that means designing for whoever has the least access first, not the easiest group to reach. Everyone else falls into place behind them.

He told the story of a housing association that built polished micro-videos for maintenance workers, then discovered nobody could watch them, because the workers were in vans between jobs, not sitting at a desk. 

Related: 11 microlearning examples that can boost learning impact

The fix was almost embarrassingly simple: strip the audio out and turn the videos into podcasts people could listen to on the road. 

Same content, a completely different access point.

Tom’s version of the same problem came from a previous role at a water company, juggling contact centre agents at desks, engineers out fixing pipes, and water quality scientists who “probably don’t need my eLearning to help them at all,” but still needed support of some kind. 

Once you’ve accepted that one journey can’t fit everyone, the fix isn’t more journeys. 

“What we’re doing is we’re designing for outcomes, not journeys,” Andy said, comparing it to a sat nav offering two routes to the same destination: one faster, the other more scenic, but both arriving at the same end point. 

Give people ownership over the route, and you’re solving two problems at once: relevance and motivation, since autonomy is one of the strongest drivers of engagement in self-determination theory, the same territory Dan Pink covered in Drive.

AI‘s role here is more interesting than the industry’s first instinct suggested. Early conversations were mostly about generating more content, which was never the shortage. 

The more useful shift is AI connecting people directly: surfacing “the right people that you might not know in your organisation who have a skill set or an experience,” as Tom put it, rather than routing everyone through the same generic course.

Friction is a design failure, not a technology problem

A good chunk of the conversation was deliberately unglamorous: how people actually get to what you’ve built for them.

Andy’s rule is simple. Design for the technology the end user genuinely has, not the one you’d prefer they had. In one of the most restrictive environments he’s worked in, a secure prison, that ruled out a laptop and even an iPad. 

His only available tool, in his own words, was “a roll of wallpaper,” the one surface he was allowed to deliver learning on. 

Elsewhere, he’d seen a company print QR codes on the back of staff lanyards linking to a weekly video from a senior leader, because a lanyard was the one thing everyone already had on them.

Tom brought this back to a principle he’s carried since early in his career: “If I can’t get to the point in three to five clicks…  it’s poor design.” That applies directly to platform choice. 

Single sign-on sounds like a minor technical checkbox until you add up how much time your people function spends resetting passwords, and how much friction that puts between a distributed worker and the answer they actually need.

Andy’s framing for all of it: this is a customer service problem, not a learning one. “We are providing a customer service experience for us learning and HR people,” he said, and reducing friction isn’t a nice-to-have on top of that. It’s the job.

Community doesn’t happen by accident

Social learning is one of the easiest things to get wrong at a distance, usually by confusing it with social media. 

A channel isn’t a community, and posting in one doesn’t make people learn from each other.

Andy’s fix is to give people something worth connecting for, not a space they’re told to use. 

He compared it to the structure of an atom: enough positive charge at the centre to pull people into orbit, even the sceptical ones. Fake reasons to connect don’t work. Real problems to solve do.

One approach that holds up particularly well in distributed teams: guilds, borrowed from software development. 

Rather than a generic open space, you build something specific, a front-end development guild, say, where everyone in the room understands the work and can actually judge a good solution when they see one. 

Andy argued L&D’s role isn’t to run the guild itself. It’s to build the conditions the guild needs to grow in.

The other thing worth letting go of is control. 

Andy’s experience is that healthy online communities self-correct: someone posts something unhelpful, and the community handles it, often better than a moderator would. 

Related: Social learning examples: real-life use cases to take away

That only works if you trust people to behave like adults, but the trade-off is a far more powerful learning experience than anything L&D could police into existence.

The metric most L&D teams still get wrong

There is often a gap between learning activity and actual organisational performance.

Andy detailed this more when he said: “We are very good at measuring the things that are easy to measure: attendance, completion, engagement, satisfaction,” he said, “the performance-focused team are not using learning metrics. They’re using organisational metrics.”

He likened bypassing thorough root-cause analysis to visiting a physician expecting quick pain relief, only to receive an MRI scan—a necessary step when the underlying issue demands genuine investigation rather than a superficial band-aid.

He’s seen award entries claim a management programme cut turnover by 15%, with, in his own assessment, “very little correlation between those things.”

Tom’s own cautionary tale came from early in his career, chasing a brief to bring call handling times down. 

He spent months on it before realising the board’s actual concern was never speed: “It was a money question… the more calls we get through, the more money we make.”

Once calls got too fast, complaints rose, and so did the fines that came with them. 

“We fundamentally misunderstood how these things interlink,” as he put it, mistaking correlation for cause.

Timing compounds the problem. Impact can take a month, three months, sometimes six to show up, and Andy admitted to bailing out on measurement too early more than once himself. 

The fix is building a follow-up nudge into the design from the start, rather than chasing feedback afterwards. 

Tom’s current experiment: a short voice-note style feedback tool sent by WhatsApp rather than email, since that’s actually where his field workers are. 

The early results are already proving his point about rating scales: they generate data, but “it actually obscures the level of insight that we really want to get our hands on, especially from teams who are spread out.”

Wondering where to start?

If you’re building for a distributed team from scratch, Andy’s advice is to resist starting with content. 

Start with context: personas for the different groups in a large organisation and opt for direct conversation if you’re small enough to have it. 

Related: The LMS adoption guide

Then apply the connectivity filter, asking whether something genuinely needs to be synchronous, or whether async should be the default.

“Let’s look at asynchronous connectivity as a really powerful design tool,” as he put it.

No two distributed teams look the same, so pick one idea from this piece and test it small before you scale it.

Pull it all together, and the pattern repeats: design for connectivity, not proximity.

Build for the hardest-to-reach person, not the average one.

Treat friction as a design failure, not a technology problem. 

Give people a real reason to connect, not just a channel to post in.

And measure against outcomes, not activity, or you’ll never prove any of it worked.

Get that right, and distribution stops being something you manage around and starts being how your team actually works.

More from this series

This was the first of five sessions in BuildEmpire’s webinar series in partnership with Totara. 

Follow our LinkedIn page to register for the next one, where we’ll have another guest tackling more big learning ops challenges.

And sign up for our newsletter to get more insights on learning and development just like this.

FAQs

What does designing for connectivity mean in L&D?

It means building learning around how people can reach each other and the support they need, wherever they are. You stop building around getting everyone into the same room. In practice, events stop being the default. Async access, peer networks and low-friction tools do more of the work, and synchronous time is kept for the skills that really need it, like emotional or practice-based learning.

How do you replace informal learning when a team goes remote?


Start by auditing what used to happen around the edges of your events: coffee-break problem-solving, overheard advice, watching an expert at work. Then rebuild each one on purpose. A digital lunch-and-learn can stand in for shadowing. A forum thread or wiki that people are actively pointed towards can stand in for corridor chats. None of this replaces itself, so it has to be part of the design brief from day one.

How should L&D teams measure the impact of learning for distributed teams?

Measure against organisational outcomes, not learning activity. Attendance, completion and satisfaction are easy to track, but they don’t prove performance improved. Agree the business problem up front, give impact time to show up (often three to six months), and build follow-up nudges into the design. Use channels your people already rely on. For field teams, that might mean WhatsApp voice notes rather than email surveys.

Subscribe to our newsletter ✉️