I’m learning more about products to support the evolution the way we work and collaborate. As I dig deeper into the problem space and talk to founders who are designing their own company ‘Operating System’ there are a few questions that persistently stand out for teams adopting distributed work:
Sync vs. Async: There is a tension between fully synchronous work with teams in the same time zone vs. fully asynchronous work with teams spread across time zones and the response is typically polarizing. I think there is a plenty of white space for new products that could work just as well for both sync or async work. Slack is a good example of a communication tool that could be used for async or sync communication in the same product. “A Slack message lets content persist for a delayed loop, but also means that the loops can become so short that loops are near realtime” (Alexander from Remotion articulated this to me). The more important part is creating a culture that supports the use case – i.e. there is no expectation you’ll respond to Slack messages immediately for async dominated cultures. There are also opportunities for better tooling in rich media communication involving images, video and audio communication that seamlessly traverse both async/sync work. I’m excited to see what companies like Remotion, Claap and Rock do in this area.
Process vs. Tools: Even over innovation in tools, defining and agreeing on a process and culture for work is important for effective collaboration, as noted above. The most successful products will be flexible tools that are able to codify process and culture within the tool and allow businesses to customize their internal ‘Operating System’. These products are inherently difficult to design as flexibility/customizability comes with complexity of learning although this is likely a solvable problem (e.g. predefined templates and workflows). I’m excited about what we are building with P2 at Automattic, and we’re just getting started.
Human vs. Product: Many teams will be working in a distributed way for the first time, and will look for help from people with experience and expertise especially at scale. I think that consulting with experts will likely be very helpful for companies adopting new products/processes/cultures as they move to distributed work. I expect a hybrid approach (human & proprietary products) will lead to the best outcomes as more teams will be effectively onboarded into a new paradigm of work.
I’m looking forward to digging deeper into each of these areas personally as well as meeting companies who are exploring these problem spaces.
The way we build software and collaborate is going through an accelerated evolution as more organizations adopt distributed and hybrid (partially in person) work. In both cases, tools and processes will be designed for distributed work first, which can then be adapted to in-person more easily than the other way around.
There is a lot of innovation coming in the tool stack to facilitate these new practices, which I’m personally excited about and plan to follow closely.
The principles that I think will become the most important for these tools are:
Asynchronous: Tools should enable both asynchronous and synchronous collaboration seamlessly. This should apply to both short and long-form communication (which should also have separate interfaces). Examples of tools that do this well are WhatsApp and Slack, which are both probably more important to me than email now.
Transparent: Organizations will move more towards ‘transparent by default’. This will allow more people to have more context and create more trust in organizations. A challenging problem to solve is information overload, allowing teams to better separate signal from noise, and picking most important things to consume and act on.
Connected: Organizations will want to collect and record more data on work created in the organization. Tools will need to be more connected (i.e. use APIs to talk to each other better) and information will need to be better organized and accessible across the organization.
Consistent: To be effective, a minimum set of collaboration tools need to be accepted and used by the organization, which can be difficult at scale as it may involve both cultural and behavioral change. This is pretty self-explanatory (I don’t go into more detail below).
Measurement: As work moves to the cloud, and we collaborate digitally, we will need more tools to measure productivity and organizational effectiveness, culture and morale.
Human: There will be more focus on being human and building broad and deep relationships inside and outside organizations. In person time is still great for driving creativity, serendipity, building trusting relationships, and humanizing work. We will find more ways to simulate these experiences virtually.
I’ll explore these in more detail below.
Building a culture, a set of tools and a set of practices that allow for asynchronous work is the foundation for distributed teams. It’s more inclusive because it allows for people in multiple time zones (or working hours) to process information and give feedback. Systems that work asynchronously that can be adapted seamlessly to work synchronously (e.g. Slack) are great where communication can be organized around projects, teams or topics.
I think this should apply to audio, video and text. I’ve not come across tools for async Audio and Video (possibly Loom) in the workplace. I used WhatsApp personally for sync/async text and audio the most. We recently took a long (1.5hr) townhall video and ‘chunked’ it down to its components and pulled it together in a blog post so that teams in different time zones could consume it asynchronously. It was very well received, especially as we did it very quickly, so it was ready in a few hours after the presentation (but a tool would help do this faster).
There are arguments that asynchronous work can slow down the pace of iteration or reduce ‘riffing’ off each other to create better solutions. I think that these are fair points, but most of this kind of riffing is useful at crossroads or can happen in very small groups and teams can create synchronous time for this if necessary. I think synchronous collaboration (and in person) is especially effective for new projects which require finding product market fit, where rapid iteration and creativity are even more critical.
I think that more companies will work more openly in the future. We will trust our employees with more, and they will have more context for their work. This applies to both short form communication (chat) and long form communication.
In order to enable this (particularly for long form communication) we need a set of tools that allow employees to be able to collaborate in the open. At Automattic we use a tool called P2 which allows us to publish anything openly (structured as a blog post) and for our colleagues to like, ask comments and questions and collaborate in the open (Notion also works well). We’re able to pull in information from other tools and embed them into the post or link to other areas of work that are relevant. We need to make improvements on how this information is organized and the ‘state’ of a post (e.g. is it ‘active’ or ‘closed’? which project does it relate to? how high priority is it?). We’ve tinkered with some ideas but not settled on anything just yet as we were worried about increasing the friction to share with colleagues.
In addition to building systems to share openly, we also need to think through the subscription and notification systems to alert people to the right information they need for their work at the right cadence and the right priority. Different people need different levels of breadth vs. depth depending on their role.
A crucial benefit of working openly and making this information easily discoverable (indexed, searchable) is that the work exists regardless of the organization’s mix of people. As employees move to different teams or companies, or when new people join the company the decisions and the reason behind these decisions is always available.
Organizations want to control more of their own information. As we rely more and more on external SAAS tools to power our work our internal data is more fragmented than ever.
Organizations need to be able to extract and record information from these tools which is currently difficult and requires a lot of custom integration work. Many SAAS tools make this difficult because they know that we are less likely to churn if we are reliant on their platform as a source of record.
Creating connected tools and workflow that enables data to move between these tools and ultimately be owned and stored by the organization is important. Once this (difficult) part is complete, building a UI (and search tool) to discover this information is a natural extension.
We don’t have good systems to track productivity for individuals, teams or projects especially as our teams become more distributed (and tools become more cloud based) and we become more output focused.
Managers need both qualitative and quantitative data to monitor teams more objectively with less bias, but employees also need to feel like they are part of the process and are not being micro-monitored.
Organizations need to log and visualize this data over time and understand that this is an input into productivity and does not tell the full story.
Relationships are important for collaboration and teamwork. Trusting relationships in our immediate teams and around the organization can lead to more productive, more creative work with more candid conversations that get to better outcomes faster.
Even at Automattic, which has been distributed since 2005, we’ve relied on in person team meetups and a global ‘grand meetup’ to help build relationships and foster serendipity in the organization. There is value to seeing colleagues in person, enjoying lingering (less transactional) conversation, and eating and drinking together.
As we move towards more distributed and hybrid models of work, we will need to make sure that we create opportunities to build relationships (deep and broad), humanize our interactions during work, learn from each other and have fun with each other both within and outside our organizations,
Hiring and onboarding of employees also evolves in a distributed environment. Hiring may take longer and leverage more text based (short and long form) collaboration trials versus traditional in person interviews. There are advantages to this process — it feels more two-way than one way, and helps remove more bias, and is more reflective of our actual work.
Onboarding and training employees needs a clear process which can be less rigid than typical onboarding bootcamps at larger organizations (and asynchronous). To achieve this we need better documentation and need to humanize the process as much as possible (e.g. pairing new folks with buddies, recording welcome videos for context etc) while giving employees the tools to onboard and contribute at their own pace (with guardrails, of course).
I remain very positive and excited for the future of how we build software and collaborate as humans. The more we can remove physical barriers to build high quality creative products the more we can improve liquidity in the global labor market and find the right people for the right jobs regardless of their location. This is is an exciting future, and better tools will continue to power this movement.