A Fully Distributed Working Model

Introduction

Running a fully remote and distributed team may seem like black magic to many, but here at TheoremOne we believe it is the foundation for the modern workforce and we’ve been a remote first working organization since we were founded over 12 years ago. 

Remote working means working from any location — not necessarily working-from-home — and with the correct practices and tools in place, it enables our teams to work at their peak no matter their location. Teams around the world and across industries are increasingly gaining efficiency and flexibility and a good work-life balance through remote working. This document explains the core practices for remote working that we’ll be using as we begin a distributed engagement with clients.

At TheoremOne, we set out to build a product development practice based on the benefits to productivity and creativity that remote working can bring. Using established technology and modern decision making practices we have designed and implemented a series of processes that ensure our teams are as productive and fulfilled as ever. As technology and corporate security practices progress, the old challenges of communication and data accessibility are decreasing, allowing remote workers to unleash their productivity potential from wherever they are. 

Distributed working is a growing trend among organizations and allows companies to maximize the working hours in a day. The experience of being in a distributed team can range from the simple digitization of the processes that you’re used to in an office to changes in the structure of how information originates and spreads which leads to major shifts in the way work gets done moving towards more autonomous teams that are mission-oriented and empowered. 

There are many advantages to working in a distributed manner, starting with the obvious lack of a commute which saves employees and organizations valuable time and money. By the same token, distributed work facilitates increased efficiency, because team members can spend more time in focused, uninterrupted delivery.

When constructing a distributed team it’s essential to clearly define the communication responsibilities of all team members and ensure that everybody understands and commits to ensuring their communication follows the standards set by the team. Remote working is all about trust and transparency — trusting your teammates to get the job done. This document outlines some of the best practices to follow with trust, transparency and productivity in mind.

At TheoremOne, we set out to build a product development practice based on the benefits to productivity and creativity that remote working can bring. Using established technology and modern decision making practices we have designed and implemented a series of processes that ensure our teams are as productive and fulfilled as ever.

We’re Leaders in Distributed Collaboration

TheoremOne is a global leader in distributed and remote collaboration. We’ve been doing it for over 12 years and have engaged in projects that leverage distributed collaboration with dozens of major companies around the world.

We have successfully delivered projects with team sizes ranging from three to fifty with wide geographical team distribution. It’s rare for TheoremOne staff to work together in the same place for more than a few days a year, but we still manage to deliver outstanding results due, in part, to the way we have proactively designed our framework for communication and collaboration.

For many of our clients, working with TheoremOne is their first experience engaging in a model that enables team members from within their organization to collaborate remotely. We have become experts in helping these organizations reimagine and re-envision their core assumptions about how work should be done. As we empower these organizations with tooling, processes, and new ways of thinking, they are able to derive tangible benefits that scale across their enterprise including: access to new global talent pools, increased employee job satisfaction, increased team efficiency, and lower overhead. Some of the many companies that we have helped on this transformative journey include:

Not only do we help our clients directly with hands-on advice and consulting work, we also help define standards for remote collaboration, and build tools that facilitate it. We’re excited to apply our decade of organizational experience and expertise in distributed collaboration to empower clients to take advantage of new tools, methodologies, and ways of working during this time of global disruption. 

The Foundations of Distributed Collaboration

Our core model for distributed collaboration is based on a set of strong foundations:

Flexible Tools
It’s a common misconception that individual work, like software engineering, does well remotely but that team-based work, such as brainstorming and creative collaboration, does not. In reality, many types of collaborative work can be done remotely if teams have the right tools. The key is to pick the most reliable, robust, and lowest friction tooling — and be willing to change tools as the project or team needs evolve.

Accountability
In a distributed environment, each team member must be empowered to make decisions and then be held accountable for the result of those decisions. This will enable velocity to increase, and actually improves the quality of decision-making.

Depth in Work
Shallow work is the multi-tasking most professionals are familiar with today — you begin a project, but you are also responding to instant messages, emails and phone notifications. This is shallow work, and it’s what most workers do day-in and day-out. Depth requires focus. To be all-in on a task for a block of time allows team members to truly tap into creativity and quality. Deep work is where quality is realized.

Effectiveness, not Busyness
Teams must orient around shared goals and priorities that are assessed against two simple measures: Effort and Impact — and then apply disciplined decision making to ensure that backlogs aren’t populated just by tasks, but by the most important tasks at any given time (e.g. those that have the highest impact).  

Define Clear Expectations for Communication
Teams must define clear expectations for how communication will work at the beginning of each project. Teams must be allowed to self-organize around the methods and tools they choose to achieve these expectations. A bias towards asynchronous communication is also key to building the flexibility and discipline required to work across multiple disparate timezones. 

Distributed Collaboration Cheat Sheet

The following cheat sheet provides practical suggestions and guidance that our teams use day-in and day-out to maximize effectiveness whilst working as a distributed team:

Embrace Flexibility
Teams spread across global time zones must work harder to remain connected, and will often need to work early or late in the day to connect with colleagues. Take this into account and try to build working groups who are time-zone aligned where possible.

Build Trust
Trust is easier to build if teams have been working together for some time, and especially if they have met in person. For colleagues collaborating over long distances or multiple time zones who have not met, trust may be low. Ensure team members have some time to interact socially (via video) as this will build a human connection and increase trust and productivity. 

Be Empathetic
For many, remote collaboration is a significant change to life and work: recognize and acknowledge that change and be patient as everyone adjusts to the new ‘normal’. Understand that many will be in challenging situations (kids in the background, limited quiet or privacy, social isolation). Make a point to connect personally; inquire about others’ well-being.

Communication Styles
Be clear and conscious of your communication style with colleagues. Use the appropriate tool depending on the message you want to convey. Be respectful of time and understand your colleagues are probably just as busy as you are.

For topics that in a colocated office we would typically book a conference room to discuss as a group, we have a few choices:

• Use Video Conferencing as a virtual conference space
• Create topic-specific Instant Messaging channels (e.g.: “#search-service”)

The meeting lead then posts a summary of what was discussed in chat as a reference.

Don’t Sit Waiting for a Reply
When sending an instant message, it’s wise not to wait for a reply. Remember, the other person could be coding, designing, or in a meeting with a stakeholder. If you need to chat with someone urgently, send them a message, without concern of the time or their working hours, they will pick it up when they can.

Use Instant Messaging and Email to Schedule Discussions, not to Have Discussions
Instant Messengers (like Slack) are at their best when used for brief questions, and with channels such as #gaming, #random and #jokes acting as virtual break rooms. However, they are not ideal for in-depth discussions and decision making. For decisions that need discussion and, or, consensus, use Slack or email to schedule a video meeting and spend that time focusing on the outcome without distractions.

Use Reminders
Use the Slack /remind function (or the equivalent in your messaging tool) to minimize open loops. Some examples:

• /remind @person to reply to this channel Tomorrow at 9 am
• /remind me to check this channel tomorrow at 9 am
• /remind #channel to pick up on this topic tomorrow at 9 am

Leverage Always-On Video
Some team members keep an open Video Call (e.g. Google Meet) session on all day, making it instantaneous to speak without setting up a meeting. We think this is a great practice, especially when combined with formal offices hours.

Office Hours
Team leaders should define weekly blocks of time that any member of the team can book in order to encourage transparent and open communication across reporting structures. 

Be Responsive
Team members on remote teams must proactively inform the team in advance of their active working hours as well as how to reach them in case of an emergency outside of those hours. The TheoremOne Engagement Manager will capture all team member working hours and escalation paths and document these in a project Wiki. Being responsive ensures teams collaborate in a timely manner. TheoremOne recommends the following expectations for responsiveness on various communication channels:

Distributed People Management & Support

While the right tools and processes are important for distributed work, organizations — and the products and services that they deliver — are fundamentally about people. 

People drive the organization towards success and ultimately people being successful means organizations are successful. For remote working to be sustainable, it is critical that we consider the employee experience. Becoming deliberate about how we engage, motivate, provide feedback, and support our employees will be judged especially in uncertain times. Here are a few best practice recommendations to help transition towards remote working:

Onboarding 
TheoremOne recommends having processes and content in use for onboarding new team members. We recommend following up the onboarding with a Buddy System to help new remote team members settle in. The buddy should ideally be someone at the same organizational level as the new employee. 

Principles for Distributed Onboarding:

• Use a team Wiki (e.g. Confluence / Notion / Google Sites) to catalogue and prioritize the most important onboarding content
• Create an onboarding checklist; institute a “buddy” to onboard new people to the team
• Have regular checkpoints, on-board new members exactly like they would be on-boarded in the office.
• Make use of the tools available such as video calls to truly make new employees feel welcome

Feedback
TheoremOne recommends weekly ‘one-to-ones’ between leaders and each team member, with follow-ups as required. Weekly feedback sessions with client stakeholders are equally important to understand, align and course-correct where needed. In cases where trust is still being built — communicate, communicate, communicate. Be transparent, keep electronic boards up to date, share dashboards, invite and answer questions.

Principles for Distributed Feedback:

• In-context feedback during/after routine collaboration (e.g. remote pairing)
• Regular ‘one to ones’ check-ins over video calls.

Social
TheoremOne recommends that teams set aside some regular time for virtual socializing, games, remote sports or to do something else non-work related together over video conference. This might be a short period (10-15 minutes) daily or a longer (1 hour) period weekly. Social wellbeing is very important to allow remote employees to keep a sense of belonging and social inclusion. While decisions made around office coffee machines may be familiar in traditional workplaces, the input is limited to those present. Those who are not present feel left out, and they’re missing an opportunity to hear different perspectives. Additionally, communicate often with the team for project updates as well as non-project messages to build relationships. 

Ergonomics
Where possible, employees should have a suitable home workspace that supports productivity. The space should be quiet, free from distraction, with deskware that is comfortable for the required working hours.

Where staff are unable to find a suitable ergonomic space, look to support them with tools such as noise-cancelling headphones, laptop stands, lighter laptops etc. to turn living space into a temporary workspace and back to living space quickly.

Meetings
At TheoremOne, everyone’s calendar is open to everyone else, and anyone can respectfully take time on a teammate’s calendars. On each project, establish who is responsible for scheduling larger meetings and ceremonies. This usually falls to the Product Manager or Engagement Manager. TheoremOne recommends using the technology tools available to schedule virtual meetings.

For the Steering Committee or other leadership presentations, the Product Manager may rely on the Engagement Manager and client stakeholders to help coordinate internal calendars and schedule sessions.

Principles for Distributed Meetings:

• Just like in-person meetings, ensure that all attendees have easy access to the agenda and know the goal of the session
• Promote a camera-on meeting culture to help foster team relationships
• Leverage visual cues and built-in hand-raise tools to ensure everyone is heard during larger discussions
• Record and distribute each meeting
• Be thoughtful about the time zones that your meeting team members are in and always try to find a time that is within most people’s usual working hours. 

Tools & Processes for Distributed Working

Communication Tools
TheoremOne staff are rarely in the same place at the same time — we work from offices, our homes, or other convenient locations. Even staff in the same timezone may not share the same working hours, some people start early and finish early, others start late and some start early, take a break and carry on later. As a result we prefer asynchronous communication methods — sending a message to a colleague, understanding that they may not be working right now but that they will reply when they’re available.

Research & Design Tools
Product development begins with problem framing & research that informs our solution designs with empathy for the business problems at hand as well as for the consumers and users in that system. Whether being in-house or remote, the goal of the design team is two-fold:

• Validate the product hypothesis through rapid prototyping and user testing
• Create user interface, experience, and interaction specifications for the development team to guide the implementation

Our team developed a proven design process that allows distributed teams to create, test, and ship better designs from start to finish. In a nutshell, here’s how it works:

1. The design team collaborates with UX Researchers and Product Managers to understand users and business requirements. They use Video Conferencing, Google Docs, and Notion to collaborate and share the information effectively and efficiently. 
2. The Design Manager creates a backlog of design tasks and works with the Product Manager and client team to groom the backlog and prioritize those tasks. Backlog grooming and design sprint planning happen in Project Management tools (primary: Notion, backup: Google Docs). A typical design task incorporates multiple features into a single user-flow. This approach helps us to think about the product holistically and design features in the context of the users’ needs.
3. Every sprint, the design team picks one or more user-flows from the backlog to create conceptual designs and prototypes in the collaborative design tool (e.g. Figma). With every iteration, we increase the fidelity of the design and move from wireframes to interactive prototypes. Figma is a cloud-based tool through which the entire team has 24/7 access to the latest designs and is able to provide their feedback and share specifications at their convenience.
4. The typical design sprint for a TheoremOne - See Graphic below
5. Once the first prototype is ready our team starts validating it with users. We’ve used Respondent.io or internal stakeholders to find people who are representative of our users’ segments. For qualitative testing, we ask our participants to accomplish certain tasks using our prototypes whilst on the video call with us. We use Zoom for Video Conferencing. For quantitative testing, we use Maze to break complex flows into smaller chunks and collect specific user feedback about the quality of their experience.
6. After validating the hypothesis we create a final design specification for the development team. The design-handoff happens in Figma. It allows our development team to collect all the necessary specifications including: interaction design notes, layouts, assets, and even CSS snippets.

• Design Sprint Planning and Retrospective: Typically an hour-long video call where the design team discusses their initial plan for the upcoming two weeks and agrees on the tasks they are going to accomplish. As the project moves along, the team starts doing retrospectives at the end of this call. We would like our clients to be there to guide the prioritization of the work, although participating is not mandatory.
• Collaborative Design Worksession: We love to co-design with our clients because you are an expert in your business, and hold invaluable knowledge about how things work in your industry. To gain access to this knowledge and to provide you with frequent and regular updates, we plan one collaborative work session every two days of individual work. Typically it’s an hour-long video call where we will collaborate in Figma on the user flows, feature designs, content, and brand elements.
• Prototype Demo & Feedback Session: At the end of each sprint, we have a formal presentation of the work. The demo is typically an hour-long video call where we will present a prototype, share insights from user testing sessions, and invite feedback.

Below you’ll find the list of primary and secondary tools we use to design, prototype, test solution hypotheses with users, and handoff software specification to the development team.

Engineering

TheoremOne engineers participate in agile ceremonies and meetings using Video Conferencing and Instant Messaging tools. Some of these meetings, such as engineering standups are asynchronous, using Instant Messaging services that help communicate status succinctly — an example is shown below.

This way of reporting status in writing ensures that the act of communicating also contributes towards permanently documenting what the team is working on, blockers, dependencies and other critical information at any point in time. Additionally, we use video conferencing to confirm future plans, answer questions, and define how the team will collaborate next.

Other ceremonies, such as sprint planning require more synchronous communication than chat tools. We use Video Conferencing so we can plan and talk face to face. The leader of that ceremony then shares their screen and directs the conversation on what items or topics are being discussed.

We use GitHub to document all steps in our engineering workflow, from defining robust user stories with acceptance criteria and proposing implementation designs and plans, to reviewing work done and documenting points of feedback.

Our pull requests then capture all of these data points and act as a hub that then lives on as documentation of everything related to each item of work, the decisions made, the team thinking, and the results produced.

Through the development process, we maintain regular open communication in Instant Messaging channels, where we discuss and confirm engineering designs, dependencies and in general support each other and build trust and camaraderie.

Additional tools may be used for collaborating in real-time on architecture diagrams, API documentation, or other needs in the SDLC.

Product Strategy & Project Management

The goal of the Product Manager (PM) is to ensure that every member on the team is empowered to contribute more than just designs or code. TheoremOne PMs collaborate with engineers, researchers, and designers to articulate the product vision, formulate user research strategy, guide design reviews, manage feature prioritization, and drive feature delivery during Agile development. PMs are also responsible for being the primary channel of communication between our clients and the TheoremOne team. 

Our team has developed a product management process that employs a modern toolset to achieve and maintain a high velocity and ship valuable features quickly. Here’s how it works: 

1. Each week, we Gather Business Requirements from key stakeholders using Video Conferencing (Zoom) and Text-based Document tools (Google Docs).
2. Each week, we Create Product Artifacts collaboratively and in real time using a Product Concepting tool (Whimsical). 
3. During each two-week sprint, we Generate Functional Requirements in collaboration with the design, research and engineering leads with a Project Management tool (Notion). We will also Iterate on UI and UX Treatments with design in a Collaborative Design tool (Figma).
4. During each two-week sprint, project leadership will Groom the Backlog & Plan Sprints using a Video Conferencing tool (Google Meet), and align on the upcoming sprint priorities using a Backlog Management tool (GitHub Projects) collaboratively with engineering.
5. Each day, PMs Performs User Acceptance Testing, Triages Bugs and Documents Missed Requirements as code and features are delivered. 

In addition to these tactical processes, PMs are also responsible for communicating updates and insights to the client and TheoremOne project leadership and collaborating on strategic decisions in the product roadmap on a monthly basis. These activities include:

1. Each two-week sprint, we Present Design Updates & Research Findings to the Project Steering Committee to gather feedback and requests for change in priority of UX and UI feature enhancements using Video Conferencing (Zoom), Collaborative Design (Figma), and Slide Presentation tools (Google Slides). 
2. Each month, we Review the Established Product Roadmap with the Project Steering Committee to assess any changes required to the prioritization of the epic backlog of features-functionality planned for development in the upcoming one to two months with Video Conferencing (Zoom) and Product Strategy & Roadmaps tools (Roadmunk).
3. Each month, we Present Status Updates to the Project Steering Committee and do a product demo of shipped features with a Video Conferencing tool (Zoom).

These tools are used to support greater project consistency and organization for everyone involved, from individual contributors to senior management stakeholders:

Distributed Project Management

We will follow an agile project management framework to help manage the business and product priorities — putting us in a position where we are driving the process versus reacting to incoming priorities.

A consistent approach to priority planning — regular planned activities — makes the process of planning engineering and design priorities much more effective. This section outlines these activities and how they are run in a distributed team.

We run a number of agile ceremonies to ensure that unexpected blockers are overcome and the right services and resources are available. Below is an example ceremony list designed to minimize meeting time and maximize communication. At project kickoff we will plan the specific set of ceremonies for our engagement with the client.

Escalation, Roles, and Responsibilities

At the beginning of a project, we collaboratively design and document all of the project’s roles, participants and their level of involvement for each activity and deliverable.

We use tools like a RACI chart to document whether each participant is responsible for, accountable for, consulted on or to be informed of key decisions and deliverables. In addition to this, we clearly identify points of escalation or proxies should that participant not be able to make a decision or provide a response in a timely manner. Having these clearly identified activities, participants and proxies listed out aims to eliminate any types of delays based on lack of communication or availability. This system allows responsible parties to better plan their involvement in these upcoming activities as well as providing a mitigation plan should a key participant be unavailable for an extended period of time.  

On a day-to-day basis, such delays are a rarity as we empower our teams and individual contributors to make informed decisions based on their intimate understanding of the project’s goals, missions and underlying principles. Our teams have a bias towards action, and we push decision making down to the individual as much as is needed to reduce any unnecessary slowdowns or reduction of velocity. The number of decisions being made by the individual contributors on the team typically grows throughout the project as trust and understanding between the team grows. 

TheoremOne Roles & Escalation Levels 

The following section is our current model for the escalation hierarchy between TheoremOne and the client. Each escalation point can be contacted by phone, email, or via instant messaging.

Client Roles & Escalation Levels 

In order to ensure communication remains ongoing despite potential interruptions, we will collect multiple contact options from each participant (Email, Instant Messaging, Mobile phone number) to ensure redundancy plans are in place should any individual system fail or be inaccessible. 

We will also agree on a SLA for feedback on each deliverable or request, and have a clear and established escalation path, should we not receive feedback in a timely manner. That way, if members of the team are unavailable, their proxy or escalation can provide that feedback or input in a timely manner and our ability to make forward progress will not be hindered. 

Expected Dependencies for Successful Distributed Work

Connectivity
All team members must have high-speed, reliable, internet access at home and ideally, a backup for internet access such as the ability to tether to a mobile phone or an alternative working location.

Equipment
Each team member needs to have a computer (preferably a laptop) that is adequately configured to do their respective job (including a quality webcam and microphone). For engineers, TheoremOne issues the latest Macbook Pro or Windows equivalent (if needed).

Security
Remote equipment needs to be provisioned following security and operations requirements and procedures from the client and TheoremOne. This may involve setting up VPNs, monitoring software or anything else deemed necessary. Additional policies may be reviewed such as hard drive encryption, device hardening, SSL, MDM, Password managers, Multi-factor authentication etc.

Availability & Scheduling
Remote collaboration may require establishing additional mechanisms for determining team member’s availability throughout the day. This may include reviewing calendars to calibrate levels of access, as well as any other systems in place. Additional tools may need to be provisioned, such as Calendly for easily scheduling virtual meetings.

TheoremOne is an innovation and engineering company that advises and partners with clients on product strategy, engineering, design, and culture to build and launch technology-driven solutions for their most complex problems.

TheoremOne designs and builds effective frameworks for innovation that transform the way businesses think about and solve problems from the inside out. 

Recently named one of the top-40 fastest-growing remote companies, TheoremOne is a 100% remote organization.