Remote team culture doesn’t happen by accident - in the same way office culture doesn’t happen by accident.
In an office, culture seeps into everything. You meet for a frustrated TEA break (which is actually just a very strong coffee and an attempt to find a biscuit). You float over to someone’s desk to ask a question and emerge 40 minutes later having solved a completely different problem and set the world right. You can also tell pretty quickly when you’ve accidentally walked into a snake pit - but that’s not what I’m here to talk about.
We’re many years into this brave new remote collaborative world and I still see teams treating remote culture as something they’ll just figure out along the way. Set up a Teams workspace, book a few meetings, hire some good people and hope everyone magically gels - “what can’t be solved with a quick natter?” - first off, never say ‘natter’, secondly, quite a lot actually.
I’ve spent a lot of time working with multidisciplinary research and UCD teams across government and the private sector. The approach I’ve settled on is fairly simple: decide in advance how people will communicate, how they’ll work together and how you’ll make collaboration happen.
IF YOU BUILD IT - THEY WILL USE IT.
Not through compulsory fun. Not through another meeting about meetings. And definitely not through a corporate away day where everyone has to reveal an interesting fact about themselves - fun fact, my fun fact used to be that I have a one eyed pirate cat from Canada - not so fun fact, he’s now dead. So now not only have I lost a beloved pet, I now have lost my icebreaker.
By designing the conditions for people to do good work together.
Here’s what I actually do.
Problem one: nobody can hear you
The default remote setup can be silence punctuated by meetings.
Everyone is “heads down”. Nobody knows what anyone else is doing. Questions disappear into private messages. Decisions happen in conversations that half the team never sees.
Then someone says, “I thought you knew”, and the whole thing quietly falls apart.
So I make communication a focus, not a by-product.
Give every conversation somewhere to go
Slack or Teams, it doesn’t really matter. The principle is the same.
If something isn’t sensitive and would be useful for the wider team to see, put it somewhere the wider team can see it.
Private messages have their place. They’re useful for personal conversations, sensitive topics and the occasional quick clarification and let’s be honest - a quick aside when you’re watching a death march of an all hands. They’re a terrible place for project knowledge to go and die.
I’m a fan of open channels, with different types of conversation having different homes.
Work channels. For the actual work. Project updates, questions, blockers, decisions and all the day-to-day business of getting things done.
UCD channels. For the craft. Research methods, design patterns, accessibility, useful articles and the inevitable discussion about whether you can call five people a sample. (You can. Whether it’s a representative sample is another conversation entirely.)
I also use this as a running commentary and notes section when I’m facilitating user research - it shows openness and encourages people to join in.
A dedicated social channel. Let people be people not resource drones. Memes, weekend plans, pictures of cats, questions and conversations that have absolutely nothing to do with the project.
Focused project channels. For the people working on particular problems to get into the detail without everyone else needing to follow every twist and turn.
This isn’t about creating 47 channels and making people complete a training course to work out where to post.
It’s about removing the guesswork.
Work chat doesn’t get buried under memes and inside jokes. Social conversations don’t feel like they’re interrupting something serious. People can follow discussions, find decisions and understand what’s happening without needing to be personally invited into every conversation.
It also means new people have a way into the team. They can read what’s happening, join conversations and learn how the team works without having to rely entirely on someone remembering to bring them up to speed.
There’s a lot of value in making knowledge visible rather than keeping it locked away in people’s heads.
Someone has to start the conversation
A channel structure is just furniture - You can build the most beautifully organised Teams workspace in the world, but if nobody uses it, you’ve essentially decorated an empty room.
Communication needs to be proactive.
I try to model that behaviour myself. If things are quiet, I ask the question first. I share something interesting or weird that’s happened. I admit when I don’t know something. I make it clear that asking questions and talking openly are normal parts of working together.
Because people take their cues from the environment they’re in.
If the person leading the team only communicates through formal updates and private messages, that’s a pretty strong signal about how everyone else is expected to behave. If the lead is visibly engaging in open conversations, sharing work and asking for help, it becomes easier for everyone else to do the same.
And this is about more than posting updates.
It’s flagging a blocker before it becomes a crisis. Explaining when a decision changes. Letting people know when you need input. Sharing progress before somebody has to chase you for it.
Nobody needs a running commentary of your entire existence.
“Going to make a coffee.” K.
“Back from the toilet.” Didn’t need to know, thanks,
“Thinking about the problem.” I mean, that’s what we’re paying you for?
I don’t need to know a running feed of your life events like it’s Facebook in 2006.
We’re making sure people have the information they need to work effectively together.
Problem two: nobody talks unless there’s a meeting
Let’s talk about meetings. Or, more specifically, the assumption that because we’re working remotely, we need to schedule every possible interaction in advance.
This is not the answer.
But I also don’t think the answer is to remove structure entirely and hope people spontaneously collaborate through the magic of Microsoft Teams.
Remote teams need opportunities to work together. They just need those opportunities to be useful, accessible and flexible.
Build collaboration into the calendar
One approach I’ve found useful is having standing meeting invites after stand-up that anyone can claim for team collaboration. A team I recently rolled off had standing meetings every Monday, Wednesday and Friday - this worked beautifully.
The time is already there. The invitation exists. People can use it when they need to get together to work through something.
Need to pair on a problem? Ask in standup.
Want to work through some research findings with a designer? Claim the session - it’s already free.
Got a knotty question that would take 37 messages to explain in Slack? Ask for a team to get together.
It’s wonderfully simplistic.
These sessions are open to the team. They’re not owned by one discipline or reserved for people who happen to be invited to a particular project meeting.
And there’s a small but important part of the process: if nobody has claimed the time, the scrum master or delivery manager prompts the team during stand-up.
It’s not about filling a calendar, it’s about enabling collaboration as standard - when somebody does need to collaborate, the opportunity already exists.
They don’t have to negotiate everyone’s availability, find an empty space in six calendars and wait until next Thursday to make progress.
The scaffolding matters
What is key is for your scaffolding to be flexible and malleable - but there. Infrastructure is there, but how people use it remains flexible.
We’re not saying that every collaboration slot must be filled, that every problem requires a meeting or that people have to work together in a particular way.
We’re creating the conditions for collaboration to happen easily.
It’s wiggly scaffolding - like squidgy Lego.
The assumption is that people will sometimes need to work together, and the team’s way of working already accounts for that. Instead of collaboration being an exceptional event that somebody has to organise from scratch, it’s an expected and supported part of the working day.
That distinction matters.
If collaboration depends entirely on an individual being confident enough to ask for help, proactive enough to organise a session and lucky enough to find a time that works, you’re putting a lot of unnecessary friction between people and the support they need.
Build the opportunity into the system and you make collaboration easier for everyone. The quieter person who doesn’t want to impose. The new starter who isn’t sure who’s available. The researcher who needs to talk through a finding with a designer. The developer who’s spotted a problem and wants to solve it before it grows legs.
And if the team’s needs change, you change the approach. The structure is there to support people, not the other way around.
Problem three: nobody agrees how we work
User-centred design doesn’t always fit neatly into sprints. I’m gonna totally derail your JIRA board. Fight me.
Research doesn’t come in two-week boxes. A discovery piece might take a week or six. Recruitment can eat your plan alive. You can’t guarantee you’ll have meaningful insight by Thursday when Thursday is the day three participants cancel and a fourth turns up being a scammer hunting for incentives.
Sometimes the research changes the direction of the project entirely.
That’s not necessarily a delivery failure. It might be the most valuable thing that happens during the project.
Agile is useful. Agile applied rigidly to research can be less useful.
Personally - I prefer working in Kanban. I like making work visible, managing flow and being able to respond to what we’re learning without pretending every activity can be neatly contained within a two-week box - but I’m not a dick about it.
If a team works in sprints I adapt, you should too. Your organisation might have established planning cycles, ceremonies and reporting requirements. Research that exists entirely outside those rhythms risks becoming invisible to the people making decisions.
So I map the work to the delivery cadence.
We can work with sprints. We can use Jira. We can have tickets. We can report progress in a way that makes sense to the wider team.
The important thing isn’t whether we’ve chosen the One True Agile Methodology.
It’s whether everyone understands what we’re doing, why we’re doing it and how it connects to the work around us.
Everyone has tickets
This is one of the simplest things I try to do - everyone has tickets on the board. Not just developers. Not just the people whose work ends up in a working piece of software.
Everyone.
Researchers, designers, content designers, delivery managers, leads. The work is represented, and everyone can see the board. Research planning, recruitment, interviews, analysis, playback. Design exploration, prototyping, iteration. Whatever the work involves, we make it visible in a way that’s useful to the team.
Why?
Because if the work isn’t visible, it’s remarkably easy for everyone else to assume it isn’t happening. A week spent recruiting participants, planning a study, sorting out ethics and consent forms or working through a mountain of data can look suspiciously like a week in which nothing has been delivered.
Unless you can see the work.
The board gives the team a shared understanding of what’s happening. It makes dependencies visible. It helps people see where somebody is blocked, where capacity is tight and what needs to happen before the next piece of work can move forward.
It also creates a much more honest conversation about priorities.
If somebody asks for another piece of work, we can look at what’s already happening and work out what needs to change.
Not guess. Not quietly pile another responsibility onto somebody because their calendar looks less frightening than everyone else’s. Look at the board. Have a conversation. Make a decision.
And it applies to me, too. If I’m asking everyone else to make their work visible, mine should be visible as well.
A ticket isn’t a weapon
I’m not suggesting we turn every human activity into a Jira ticket and start tracking how long somebody spends thinking. Trust me, I have been on that team, and that didn’t last very long.
The point of making work visible is to help the team understand and manage the work. It isn’t to monitor whether somebody has been sufficiently busy.
A good board creates clarity. A bad board creates fear. How many boards have you seen where an officious delivery manager sighs when they get to the ‘blocked’ column and then asks with dripping condescension why design is ‘blocking the devs’?
Research is uncertain. Discovery involves exploration. Sometimes you need to follow a line of enquiry that turns out to be a dead end.
The board should help us have better conversations, not replace those conversations.
And if people are afraid to move a ticket, flag a blocker or admit something hasn’t worked, you’ve got a culture problem that no amount of Jira configuration will solve.
Problem four: nobody knows each other
Right. Let’s get back to the fun stuff.
Because I don’t want a remote team where every interaction is transactional. Every message has a purpose. Every meeting has an agenda. Every conversation exists to move a ticket from one column to another.
People aren’t vending machines for deliverables.
We build relationships, develop shared references, discover common interests and occasionally spend 20 minutes arguing about something completely irrelevant to the project.
That stuff matters.
Not because everyone needs to become best friends with their colleagues. You don’t need to organise a mandatory escape room or make everyone share a fun fact on Monday morning.
Please don’t.
But people need opportunities to get to know each other beyond their job titles.
The question of the day (QOTD)
In our social channel, I try to prompt conversations with a question of the day.
Sometimes it’s something straightforward. Sometimes it’s a question designed to get people thinking. Sometimes it’s something utterly ridiculous. BUT SAFE FOR WORK.
The important thing is that it gives people an easy way into a conversation.
And these questions often go off the rails in the best possible way.
A seemingly innocent question can turn into a long discussion, an unexpected shared interest or an argument that nobody could possibly have predicted when the question was posted.
That’s the good stuff.
You get little glimpses of the people you’re working with. You discover things you wouldn’t necessarily learn in a stand-up. You develop running jokes and shared references that make the team feel more connected.
And you don’t need to schedule a meeting to make it happen.
The question is there. People can join in when they want to.
Some days, the conversation takes off. Other days, it gets two replies and quietly expires. That’s fine. We’re trying to create opportunities for connection, not hit a social engagement KPI.
The social channel is there for people to be human beings, not to demonstrate their enthusiasm for team culture.
Participation should be optional. Some people enjoy a busy social channel; others prefer to observe or engage occasionally. Both are perfectly reasonable.
The point is to make connection possible without making it compulsory.
Don’t confuse socialising with culture
Free pizza, online quizzes and virtual escape rooms can all be enjoyable.
But they’re not a substitute for creating a team where people can ask for help, challenge an idea, share a problem or admit they don’t know something.
You can have a brilliantly organised social calendar and still have a miserable team.
Culture isn’t just what happens when the work stops.
It’s also what happens when the work gets difficult.
Which brings me to the bit that matters most.
Culture is what happens when things go wrong
You can have open channels, well-organised boards, standing collaboration slots and a question of the day.
All useful things.
But none of them will save a team where people are afraid to speak honestly. If somebody raises a concern and gets punished for it, people learn to keep quiet. If every new request is treated as an emergency, people learn that nothing can be prioritised. If a senior colleague routinely bypasses the agreed process and makes decisions in private conversations, people learn that the board is largely decorative.
You can’t put psychological safety on a slide and then make somebody regret raising an uncomfortable truth.
You can’t tell people to communicate openly and then punish them for disagreeing with you.
And you can’t claim to trust your team while demanding constant proof that they’re working.
The systems matter, but the behaviour around those systems matters just as much.
The delivery manager who spots a blocker and helps remove it. The researcher who can say the evidence doesn’t support the team’s favourite idea. The designer who asks for another opinion. The lead who admits they got something wrong.
Those are the moments that build trust.
And when something does go wrong, the team needs a way to deal with it.
Sometimes that’s a quick conversation. Sometimes it’s a more difficult discussion about expectations, workload or behaviour. Sometimes you need to change the process because the process is creating the problem.
What matters is creating an environment where people can raise problems, work through disagreements and recover when things don’t go to plan.
So, what does a good remote culture look like?
For me, it comes down to a handful of deliberate decisions.
Communication is open by default. People know where to go, where information lives and how to get help.
Collaboration is built into the way we work. The time and opportunity exist before somebody needs to negotiate them from scratch.
The work is visible. Everyone can see what’s happening, understand dependencies and have an honest conversation about capacity.
The process supports the discipline. We work with the wider delivery rhythm without pretending research and design always behave like software development.
People have room to be human. There’s space for social conversation, shared interests and the occasional question that derails an entire afternoon.
Trust is reflected in behaviour. People can raise concerns, ask for help and challenge decisions without fearing the consequences.
None of this is particularly revolutionary.
Open channels. Proactive communication. Standing collaboration slots. A visible board. A social space where people can be themselves and bond.
The individual components are simple.
The value comes from putting them together into a way of working that makes good collaboration easier.
You don’t want to force people to collaborate. You want to remove the barriers that stop them doing it.
You don’t want to force people to socialise. You want to make it easy for them to get to know each other.
And you don’t want to spend your life chasing people for updates. You want a system where the information is visible and the conversations happen naturally.
The structure is there. The expectations are clear. People have the flexibility to work in the way that suits the situation.
And if the question of the day turns into a completely unhinged argument about something nobody remembers starting, even better.