Leading Design in remote and distributed teams isn't rocket science

If you have remote team members in your organisation — whether they’re designers or not — or if you have distributed offices in more than one city — then realistically you’re touching some of the issues associated with asynchronous or remote working.

Even if asynchronous or remote working is completely culturally abstract in your organisation, you’ve never considered it, there’s only four of you in one tiny office who always lunch together — or even if it’s something you personally detest the idea of and have sworn off it for the remainder of your career because reasons — you’ll still encounter some of the issues asynchronous or remote teams deal with.

This is in part because support for remote and distributed work is an inevitable end game for future businesses. The era of the ‘big city’ being essential to success is waning, while the empowerment of the provinces and a cultural drive to embrace a better way of living and working is in the ascendance. The fact is major cities are where they are due to their geographical relation to rivers, line of sight communication, rail lines, harbours and established trade routes.

These things are no longer deciding factors in your global design strategy. We have the internet now.

The good news is - it's a Design problem

In most orgs, regardless of size, design is the core power that binds development, marketing, sales, brand and business stakeholders. Effectively its role is to be the central, lateral communication channel. It defends the user, it actions and commissions research, it discovers trend, it crafts solutions, it communicates — and all of this affects the entirety of your products community, yet also the organisation itself - including the inevitable bottom line. Even if your org as a whole hasn’t realised this superpower design has to effect change, then even getting your design org to — at the very least — communicate effectively with each other, with minimal friction and shared knowledge - can only be a good thing.

I once worked in an org that was proud of it's 'low bus number'. This meant that a small group of employees had a huge amount of knowledge and therefore context - and therefore responsibility - and if those precious few employees were run over by a bus - the company would fail overnight. It was seen as a privilege to be one of those few chosen employees. To me that displayed pointless risk, and it was, as you'd expect, needlessly stressful on those precious few. It meant they couldn't take holiday, work flexibly or easily delegate. It also meant that every communication had to travel through them, every decision validated by them. This created a communication and knowledge fiefdom where knowing basic things to get a job done could often involve something of a knowledge quest for anyone 'normal'. So why did that org try to encourage a culture of 'low bus numbers'? Well, all ego aside, it was easy. It was easier to synchronise a few people than constantly synchronise everybody. It was trickle down communications - and if you're knowledgeable in any way about the realities of economic theory - you know that trickle down doesn't really trickle down. It just creates silos and vacuums.

I’ve seen several orgs struggle with these kind of synchronous / asynchronous communication and transparency problems, and the good news is there is an ever growing industry of cute sounding, pastel coloured products dedicated to solving the majority of these problems from $5 per user per month. In reality though, as you've no doubt deducted from the fact that 'low bus number' organisations actually exist, reliance on tooling is doomed to fail without a large cultural shift towards accepting remote and asynchronous concepts as being a positive and progressive development in the workplace.

One of the many reasons orgs struggle culturally with remote or distributed work is an existing regressive or inert culture of managerial control often founded in a requirement to 'be present' (aka Presentee-ism). This often flows from senior leadership, but it can also creep into teams as cultural regression - through poor hiring, org restructuring, poor cross-org communication or underdeveloped and unadaptive culture. In all these environments, as you'd expect, change is going to be hard. However design orgs are well placed to drive, mitigate and communicate change  - it’s a service design problem at heart - and designers are perfectly equipped in solving these knotty human problems with a reasonable level of empathy and an elegantly crafted solution. Let's be honest - isn't every Design leader at some level re-designing the org that they sit within anyway?

I'm not going to list the full benefits of embracing remote and asynchronous work practise - I feel we're all aware of them by now and they're well publicised. Certainly if you've been trying to hire Designers lately you'll know of the talent demand for such environments. There's a reason for that. However it's worth noting that remote and asynchronous work practise can often be misinterpreted - it is not just about people 'working from home' - rather it's a practice that respects peoples choice of environment, cadence and personality. While there are many who work from their home office and shun the two hour commute and higher house prices, there are an equal number who work in co-work spaces, alongside other mixed discipline colleagues, or simply tour between clients and offices. In truth you just don't have to all work from one office to benefit from such crucial things as top global talent sourcing, quick scaleability, simple holiday / sick day logistics, open knowledge share, diverse global culture, hyper flexible working hours, clearly defined goals, roadmaps and documentation - and the most impactful -  self-curated focused work environments. Designers are a wonderful mix of introversion and extroversion and need both periods of group discussion and periods of absolute focus. Giving them the power to curate and design these environments on a personal level is very powerful.

If you're ready to take on the challenge of building a distributed, remote or asynchronous-positive Design environment - here’s some hard-won personal opinion on some next steps, pitfalls and quick wins.

Sweat your workflow

Do the level of discovery and critique you’d do on a new product or feature launch — on your current and future workflows. Design has one of the more complicated workflows in an organisation, primarily as the work produced is often incredibly varied in scope and often open to subjective feedback.

Do you currently work face to face and have quick discussions over the desk? Great — but you need to work out how that scales in a remote environment. Sure you can FaceTime someone and have that conversation, but in a remote environment that conversation, those decisions — those actions — are outside of the team, and the rest of that team loose precious context on your decision making. Because of this, any new workflows for design need to be transparent, basic and heavily contextual. This initially seems like a large upfront investment of time — documenting all conversations and workshops, running regular all-hands meetings and recording them, coordinating time-zones for group chats — and it is.

But the benefits you gain from this investment are ten fold. It’s easier to track changes and decisions, it’s easier to onboard new staff and contractors, it’s easier for staff to take holiday, it’s easier to align stakeholders — because it’s all there for everyone to see.

Transparency of information and knowledge is your friend, and creating systems and workflows that encourage transparency and open discussion are critical to success. Making these systems and workflows asynchronous is an additional superpower, allowing offline thinking, reflection and considered commenting possible. Synchronous environments empower the extrovert and the quick-thinker over all others - don't discount slow thought, complex contexts and the power of writing as a way of structured thinking.

In my experience I’ve found a some key areas that aid this.

Firstly you need a solid accessible environment to create centralised documentation. This is playbooks, ‘why we did what we did’ and outcomes. A single source of truth. This environment needs to be easy to use and low friction otherwise it’ll never gain traction in the team if documentation is seen as a chore. You’ll also need to set expectations on the standard of documentation, where it lives, responsibilities for updating it, and who sees what and when.

Secondly you need a clear approach to workflow. I’ve placed Kanban into Product and Marketing teams with equal success — just remember it has to have maximum clarity and minimum friction — and you’ll need to, again, set expectations. Creating workflows like Kanban relies on each designer taking on some project management responsibility to maintain clarity at handover.

Thirdly, communication cadences are crucial. When do you run a crit? How do you run it? What are the timezones in play? What are the skillsets of the attendees? How do you keep your team in sync — especially if they’re cross-discipline?

Fourthly, you’ll need to focus on the design process itself and the resulting taxonomies. How do you create a brief? If no-one is there to crowd round your screen to make quick iterations — how do you do this? When you’ve created something incredible — how does it get signed-off? How do you collate and distribute stakeholder feedback? When it’s signed-off, where does it live and how can others find it?

For me I’ve found solving these problems as a team and getting buy-in on a team level the best approach. I’ve also found that (with one critical eye on tool-creep) that giving designers a choice over the tools they personally use to solve these problems to be beneficial in allowing a constant peer review of new and emerging solutions.

Treat this like a range of design problems. Get your team to work on them as a whole, and be sure to bring in all the skillsets relevant to that discussion. Have a video editing team? Copywriters? If they touch your org creatively, involve them at the kick-off discussion. Retrofitting other workflows is both painful and usually causes a lot of resentment.

Consider your whole design org

And by that I mean — not just the Product Design team. It’s easy to see Product Design, with its proximity to development and agile practise, as the perfect starting point for building a remote playbook. But think about Marketing Design and broader Creative teams, and their unique requirements. Sure they do a lot of print, video or social — but a successful design org is one that is sync, creatively, cross-discipline, and you should consider the same remote needs that a Product Designer would have applying to a graphic designer crafting MPU Advertising. In my experience it’s ‘all or nothing’ — but there are huge benefits. If your Product Designer is building a product onboarding feature, and they can see the Marketing output and message for the product in real time (and vice versa) I defy anyone to say that this level of dual asynchronous context is a bad thing. At their core, Product and Marketing design are 90% about communication of story — so if those two teams aren’t on the same page…what chance does the end user or customer have in understanding the story you’re telling?

Communication, Communication, Communication

You’re not going to be sitting next to each other — and if you are, others who won’t be sitting next to you will need to be looped in. Begin by treating any significant offline conversation as a sort of taboo — ask yourself if any element of that conversation is critical for group understanding. The worst phrase you can hear uttered in remote teams is ‘I wasn’t aware of that’. People being unaware of critical information (even if you don’t consider it critical) is incredibly dis-empowering and quickly causes silos which inevitably devolve into cliques, and before you know it you have low bus numbers. Your role is always to prevent that from happening. To solve for this, choosing your communication cadence is critical — and that cadence can be split into online and offline comms.

Online Comms (Synchronous)

This is primarily video calls. Zoom and GoToMeeting all have good cheap tools for teams and using it effectively means making clear diary touch points in your regular weekly workflows, and remembering to record and archive meetings for those who cannot attend. I’ve found having a general all-hands design meeting mid-week to be a good ‘go round the room’ opportunity to catch up and listen, and another weekly critique-specific session to be pretty much optimum. Any more than that and you begin to get meeting fatigue and attendance will drop — your designers will be having numerous other meetings themselves inside their teams, so optimising the time you have as a group is critical. Slack is also your friend, however others have found tools such as Basecamp to be better for their workflows. Either way a continuous IM channel is critical.

Offline Comms (Asynchronous)

This is likely to be split into documents, workflow and assets. For documentation I’ve had success with Notion as a powerful centralised asynchronous document environment, however Dropbox offers it’s own version which some will prefer. For workflow, Asana has a low impact Kanban and list option for managing jobs to be done. Product Designers may prefer Jira to sync better with their development teams — the best tool here is usually the best tool for the job, and that can mean multiple tools (I run Asana and Jira) but the key is to give everybody access to everything - even if they rarely use it in their day-to-day. I’ve used Trello, Meistertask — there really is no shortage of options — however considering the workflow you apply to those tools is much more important. For asset management I've found the tool selection is usually driven by cost  -  the taxonomy is critical to how useful that tool is.

Sometimes synchronous can be hard if your timezones are extreme, but even in the worst extremes, there’s usually around two hours crossover during ‘reasonable’ working hours. Of course this puts pressure on those two hours of possible communications — squeezing an entire day of discussion into 2 hours is tough, but it forces focused meetings quite quickly, which is a good habit to build. Having said that, if there’s one thing that extreme timezones do beyond encouraging better meeting hygiene — it’s that they force you to discover the benefits of asynchronous workflows very quickly.

Criticism and Feedback

In remote communications environments, the process of criticism and feedback quickly becomes core to team success. Your weekly crit sessions become very important, and it’s necessary to make sure those meetings are coordinated well to create maximum value for everyone involved. There are a few tools to help with crit and feedback, but I’ve found in running remote crit that it’s important to schedule the work being critiqued in advance so everyone turns up knowing what their involvement is — and they have time to research the context from documentation before they log in. I’ve found that the designers who leverage the best critique are the ones who communicate up front what they want critique on, rather than awaiting a generic Q&A from their peers. I’ve also found making the crit session non-compulsory to be more respectful of people’s time where there is always limited space in the diary - the teams time is reserved in the diary once a week, you just need to bring something to the table.

For critique and feedback there are, again, offline and online elements. For online I’ve found Figma to be a great centralised design tool to coordinate different design disciplines (from Product to Marketing to Brand) under openly shareable transparent URLs. Invision Studio is similar, and both tools offer prototyping, presentation and support screen sharing. For offline, these tools also offer commenting and collaboration at the core of their products. I’ve found commenting and multi-user collaboration to be incredibly useful, and is something of a game changer in distributed teams. How you use commenting and collaboration in these tools however can be a contentious discussion — it’s entirely possible for 5 designers to pile onto one artboard and begin altering someones work, and the danger of ‘design by committee’ naturally increases with such powerful features. Your team needs to work out together where their red lines are in collaboration, and have awareness of how each other work, and prefer to receive feedback.

Coaching and Leadership

Remote teams need more coaching — or they seem like they need more. This is really due to you having to schedule it rather than it happening in typical daily conversation. The benefit of that though is it causes focus, and means the coaching can have more impact. Leadership also needs scheduling, but in reality remote or distributed teams need a slightly more passive lightweight form of leadership — you’re not organising group lunches and meet-ups and seminars, now your role is to make sure everyone is in the loop, concerns are addressed, communications are clear and transparent, and agreed documentation and communication cadences are being adhered to. Does it feel less social and more janitorial? Yes. Yes it does. But it doesn’t mean that it can’t be rewarding. I’ve found distributed and remote teams need more individual attention — coaching individual designers to find their leadership qualities and embrace them. Turning your entire design org into a team of design leaders is a very satisfying proposition — more so than expensing a group lunch or dragging everyone into the office via a two hour commute to attend a meeting.

Ownership

You’re not physically there, so you need to empower your team with ownership over their own work and their own ways of working. As you move towards distributed teams, so the ‘hovering Art Director’ in you has to take a back seat. Trusting that ‘things will get done to the required standard’ now becomes a key component in how you work together. Working with your team to discuss and define ownership — and then getting them to ‘own’ that ownership — is a crucial to them being able to perform remotely and build trust — both with you, and with other designers.

Turning up

You have to be face to face sometimes. Remote is great and everything, but there’s always going to be a need to spend time with those in your org; whether that’s to connect on a personal level, gain skill transference, kick-off a complex project, or just to bond as a group. Depending on your budget, those face to face opportunities might be decided for you.

Onboarding
Any new staff member will have an impact on the teams dynamic, but it’s not realistic to get the whole team together every time you hire someone (especially if your company is scaling quickly). Involving your team in the hiring process is always good practise regardless of work culture, but involving them in the onboarding is more important in environments where hanging out at lunchtime is harder to do. I've found onboarding new people through self-guided asynchronous tasks to be really useful for both manager and new starter; spin up a task board (it might be in Trello) and get your team to contribute to it (ask everyone 'what things did I need answers to when I started?'). I usually add tasks to grouped topics such as 'people to speak to', 'software to sign-up for' and 'links to key documentation'. The benefit of this approach is the new starter gets to keep this asynchronous onboarding for future referral - which reduces stress significantly in the first few weeks on the team. I also feel that turning up to meet them on their first week is hugely important. It shows you care, sure, but it removes fear in any new starter - I've flow 12 hours to mitigate that fear. Starting in any new culture is nerve-racking, so you should do your best to mitigate that worry with quick-to-access processes and be there as a friendly face to ease them in.

Leading
If you are a leader you have to pick a cadence of turning up that is optimal for your team. I’ve found something akin to quarterly useful, especially if your business runs a quarterly OKR process to define the business or team level goals. Get on a plane. Bring people together who need to be together.

Teams
Bring teams together that need to be together. That’s obvious. If you have a remote team that all work together on one product line, find a time for that group to meet in person maybe twice a year organised around what makes sense to their work. Let that team decide that cadence, and do all you can to support their choices. However as a leader, consider who from other teams should also be there — if you’re building a commercial product, is there a benefit in bringing Marketing Design and Product Design together? If Video Production is a large part of your onboarding, shouldn’t they be essential to any face to face meet up?

All Hands
Sometimes you have to bring everyone together to meet up and get to know each other. You’ve likely been working hard to prevent team silos, but even in the best case scenario, it’s likely you’ll have designers and creatives — or key stakeholders and colleagues — that have never met in person. Most companies choose to do this on an annual cadence over a one week retreat, which is great. Do it. But does your broader design team need that opportunity as well? Large retreats can be overwhelming and with so many faces, people can find it tough to connect on the things that matter. Consider the need for a smaller retreat to balance it out with a more focused agenda.

Celebrating Diversity

One of the wonderful prospects of remote and distributed teams is that the culture enables — and promotes — diversity and inclusion. The fact that the highest paying jobs and opportunities are in big cities, and the cost of education, combined with living costs vs renumeration (especially when you’re beginning your career) means that working the best jobs at the best companies in the biggest cities favours those who come from affluent backgrounds, who most likely are white, who most likely are male and who most likely have no complexity in their background. This means that there is a huge talent base internationally that cannot access the opportunities that they might be perfectly aligned to given the chance. If you have a family you care for, elderly parents, children, a non-affluent family history, or are a minority for whom opportunity is less accessible — which let’s face it is a lot of people — you can’t just up and leave to New York, London or San Francisco to throw down $3K on an apartment rental. And why should that sacrifice — or attainment — be the defining factor in your career success? Is it because the role you are qualified for, for whatever reason, requires you to be present in an expensive city, despite the fact that it — if we are all really honest — could be done from anywhere? Is it maybe because the people who run that company could / can afford to be in an expensive city and therefore presume others can?

The greatest benefit of remote and distributed teams is you can tear up the existing rulebook and look to build a different kind of org based on talent, skillsets and experience — regardless of location, background or privilege. In design, diversity is its lifeblood. Finding and solving user problems, communicating to broad ranges of people, communities and cultures — this is what design does. But without diversity in that design team, it’s just endless appropriation. The most exciting thing about the prospect of a remote and distributed future is the basic freedom it gives in team building, and the access it gives to a broader spectrum of great talent — wherever and whoever that talent might be.