Remote Work Experiments
Experiment with remote and flexible work practices to improve collaboration and open up new lifestyle options for your team.
Among the many personal and societal tragedies caused by COVID-19, the global pandemic also triggered a giant global experiment in remote work. This gave us a once-in-a-generation opportunity to reconsider — at scale — how office jobs get done.
My team at Cornerstone OnDemand went all in on remote work in the early days of the pandemic. But we didn’t have much prior experience working remotely, so we had to trial new ways to collaborate and get things done.
Here, I’ll share some of our successful remote work experiments … and a couple of failed ones, too.
Experiments That Worked
Full Schedule Flexibility
When we first switched to remote work, we kicked off another experiment at the same time: Total schedule flexibility. We asked people to work 40 hours a week, on whatever schedule suited them best, and to coordinate as necessary with their teams. This was not a stretch for us, as Cornerstone was already a global organization, with engineers collaborating across North America, Europe, the Middle East, Asia, and the Pacific.
We ended up with a surprising diversity of work schedules. Engineers started work as early as 5am, or as late as 11am. Some preferred to work a “4x10” schedule, with four long days a week. And a few came up with more fragmented schedules, working in shorter chunks of time over five or six days. We weren’t surprised to learn this, but it was clear the typical 9-to-5 office hours are not a good fit for most people.
Allowing people to organize their work around their personal lives and daily energy levels was a big win for the team. I loved that we could support people who preferred to take an afternoon nap, or go mountain biking during daylight hours, or maybe offset a production incident on the weekend by spending Monday with the kids.
But for me, the most positive impact was something we didn’t really expect: Some parents with childcare responsibilities were able to go back to full time work, when a regular work week would have been impossible to manage. They designed their schedules around their children’s needs, getting their work in at odd times of day and night. This seemed like an amazing win from a diversity, equity, and inclusion perspective.
The team also embraced global time zone differences. With most of my team in New Zealand, and collaborating closely with teams in the US, our work week only had a four day overlap. This created natural quiet periods on Monday in New Zealand, and Friday in the US. We committed to making these meeting free days, to give teams at least one day a week for uninterrupted, deep work. And for engineers that preferred to work four long days a week, this created a full day where they could be absent without missing any meetings or social gatherings.
Focus on Documentation
Remote and flexible work calls for a more asynchronous approach to communication. You don’t always have others available to answer questions or give feedback, and it’s awkward to depend on meetings for decision making.
To combat these challenges, we trialled a more documentation-based approach to collaboration. One of the most successful experiments was to use “architecture decision record” (ADR) and “product decision record” (PDR) documents to help us make decisions.
For any significant decision, an engineer or product manager would document the problem statement, any context or constraints, a list of possible solutions, and a recommendation for what to do next. The document owner would then ask for feedback from their peers and other stakeholders, iterate on the proposal, and ultimately commit to a course of action. These documents enabled asynchronous decision making, helped us prep effectively for any discussion meetings, and recorded each decision for future reference.
In parallel, we built up a library of “how to” content. Whenever someone asked or answered a question, they would document the answer in our internal wiki. Over a few months, this built up a large library of knowledge for new or existing engineers to tap into, at any time of day or night.
We also used the wiki to share project status, team priorities, key metrics, wins and challenges, and video demos of new product features. Team members would update the content regularly, and interested parties would then consume the information when and where it was convenient for them. This was a great way to inform the team and leadership about current events, without the need for all-hands meetings or expensive leadership syncs.
Fewer, Better Meetings
With our shift to flexible work schedules and improved internal documentation, we cut down drastically on meetings. We eliminated many tactical update meetings, group decision making sessions, and other meetings that could be handled through asynchronous collaboration. Some teams experimented with moving daily standups to group chat. They would then organize a follow-up meeting when there were interesting topics to discuss.
This shift created much larger blocks of uninterrupted focus time for engineers. It also increased engagement in the few meetings we did have, because we only organized one when we really needed to, and participants weren’t fatigued from consecutive meetings.
Perhaps more importantly, we shifted the focus of our few large meetings from work discussions to social get-togethers. With the money we saved on office-based perks, we set up a regular schedule of team catchups for food and chill-out time, or team activities like bowling, escape rooms, and paintball. This helped offset the lack of daily face-to-face contact in our remote work environment. It turns out face-to-face meetings are better when you just meet for fun.
Experiments That Didn’t Work
Hybrid Work
For the first couple of years of remote work, we continued to maintain an office. We wanted to enable in-person collaboration, have our own space for social catchups, and support people who couldn’t easily work from home. Although we didn’t mandate time in the office for anyone, a couple of my engineering managers bribed their teams with food for a bi-weekly catchup.
In practice, we found that only a handful of people used the office on any given day. As our remote work practices improved, almost everyone preferred to work from home, or occasionally from overseas. We rarely had a critical mass of people in the office for in-person collaboration, so the benefits of coming in were outweighed by the drawbacks — such as lengthy commutes or childcare difficulties.
We briefly considered mandating one or two days in the office each week. But when you do this, you negate the biggest benefits of remote work, such as location-independent hiring.
Ultimately, we canceled our office lease, and offered teams the use of a shared office space instead.
No Official Commitment to Remote Work
Although we embraced the remote and flexible work experiment, we didn’t commit to support these work practices indefinitely. We wanted to give ourselves the option to go back to office-based work in the future.
In retrospect, this was a mistake. A huge benefit of remote and flexible work is that people can make major life changes, like moving to lifestyle or low-cost locations, or cancelling daycare to work flexibly around childcare responsibilities. But buying a property in another location is risky if your organization doesn’t have an official remote work policy.
We found the full value of remote and flexible work was only realized a couple of years in, when we finally made a firm commitment to support it indefinitely. I wish we hadn’t kept the team on tenterhooks for so long.
How We Measured
When you perform these sorts of organizational experiments, how do you measure what works and what doesn’t?
My best suggestion is to continuously monitor the metrics that matter most in your organization. You you can plot these over time to see how each experiment affects them.
In our case, we tracked our internal performance metrics across application delivery, process flow, operations, and customer experience. This included things like deployment frequency, cycle time, incoming defects, and product usage metrics. You can read more about these in my previous post about monthly report cards.
To our surprise, we saw very little change to any of these metrics as we transitioned to remote work. We would have loved to see a clear improvement in some areas, but we were still happy with this result: It showed that the team quickly adapted to our new ways of working.
We also measured our internal NPS, through a regular anonymous survey. And wow, did we see a change there. Six weeks into our fully remote work experiment, our internal NPS was up by over 30 points. Even though it eased back a few points once the novelty wore off, this is the largest increase I’ve seen in my career.
This sentiment was backed up by informal feedback from the team, and regular check-ins with managers and engineers. People really appreciated the freedom and flexibility of remote work, and many made meaningful lifestyle changes in response. It’s hard to imagine any other organizational change that could result in such a big quality of life improvement for the team.