Skip to main content

https://gds.blog.gov.uk/2020/10/07/what-happened-when-we-stopped-having-meetings-and-sending-emails/

What happened when we stopped having meetings and sending emails

Posted by: and , Posted on: - Categories: GOV.UK Pay, Ways of working

Screen showing October 2020 calendar with a sticky note stuck on the screen, reading “No meetings”.

At GDS, we’ve always promoted the benefits of working in multidisciplinary teams, being co-located as much as possible. Bringing together specialists to work on problems in the same building has clear benefits: interaction is easier, scrum boards and roadmaps are more visible and make coordination more fluid, and collaboration can be kicked off quickly.

But we’re keen on the benefits of remote working too. Teams can choose to work from home, flexibly, as needed, and everyone is given the tools to do so. It means they can get their head down and focus, or do the washing up at lunchtime in between meetings. People can find a balance between work and life that works for them.

All that changed in late March when everyone shifted to working from home by default. We wanted to take advantage of the change to try new working practices in GOV.UK Pay, inspired by a blog post about how they communicate asynchronously at Automattic.

So we tried to have a week where there was nothing that demanded that people be in a certain place at a certain time and making sure our messages were clear and comprehensible, giving people time to think and respond, and having more agency over how they spent their time.

Getting rid of meetings

The biggest change was to get rid of work meetings. Meetings force people to do a specific thing at a specific time, potentially disrupting their flow. We wanted to see what happened when there were no meetings in the calendar.

For our trial, there were some exceptions:

  • meetings with people outside Pay, which might have been unavoidable
  • community and line management meetings, which aren’t relevant to a team trial
  • meetings for pair programming or collaborative work, to do something together rather than to decide something

Several team ceremonies we would have usually held in a meeting, such as retrospectives (retros) or sprint planning, were substituted by colleagues providing their own updates on collaborative tools, such as team Slack channels, Google Docs or Trello boards. Tasks were assigned in similar ways.

There wasn’t a team show-and-tell scheduled for the asynchronous week, but we could have explored sharing pre-recorded segments and discussing them on Slack.

Getting rid of emails

Email is a form of asynchronous communication, but has a few characteristics that would make the trial harder:

  • it’s “push” communication, so the recipient can’t opt in and out
  • it’s closed, so only the recipients can see the information and the sender needs to pre-empt everyone who might need it
  • it’s basic, so things like version control and comment threads get complex fast

Instead, people sent messages on a team Slack channel, or created proposals in Google Docs and shared that.

Keeping things ticking over

One benefit of removing meetings is that we no longer had a reason to say people had to work specific hours. We asked everyone to work the same number of hours that they usually do, but asked them to do them at any time and in any length of blocks that they like. The exception to this was people working on Support, who had to work the times set out in our support agreement with our users.

We scheduled 2 optional social meetings a day to stay connected as a team, with a strict no-work-talk rule (so we didn’t compromise the experiment).

How it went

We ran a retro to reflect on the week, voting on various things, as well as gathering comments. Not everyone voted on everything, so the numbers are inconsistent.

On balance, more people found this way of working to be as good as or better than normal. 8 people had mostly positive feelings about working in this way. 6 were neutral or conflicted, and 2 had mostly negative feelings.

On the whole, we managed to follow the rules: 17 of 18 people broke the rules once or twice at most.

The biggest benefit for most people was having bigger blocks of free time, which allowed them to focus on a piece of work without interruption. Almost everyone found that managing their own concentration levels was easier.

The clunkiest bit of the week was planning. Each team usually spends time on working out what to do next every week, and some teams do so daily.

Most of this could have happened in Slack, but without scheduled meetings, some of it didn’t. Each team did put together a sprint backlog, but it was generally less well thought out than usual. However, 11 of 12 people thought this clunkiness was probably lack of practice, rather than a fundamental trait of asynchronous planning.

One team usually pairs all day. They struggled with the absence of a stand-up to coordinate the pairing in the morning, and to connect with the wider direction of their work.

What we learned

The trial highlighted some things that otherwise weren’t obvious.

We noticed a few instances where a process was usually collectively owned, but without a meeting to force people to engage with it, it didn’t get done. In those instances, a named person or role responsible for the process would have helped. We’ll explore whether we’d work better with a defined owner or rota for those processes, even when working synchronously.

At one point, an urgent piece of work arrived and we tried to adapt asynchronous processes to deal with it, but quickly abandoned that. When the cycle time for sensing a problem and providing a response is short, direct communication and collaboration makes it quicker to deliver solutions.

Some felt less engaged with their team, which is something we’d need to solve if we were to switch to this pattern in the long term.

The benefits people experienced tended to be related to their role. For example, product managers, delivery managers and designers generally have competing priorities for how to spend their time. An absence of meetings empowered them to prioritise freely, rather than having to spend time on whatever felt important when meetings were scheduled. Developers tend to work more directly from a backlog, so felt this benefit less.

Next steps

The way that remote working has blended people’s experience of work and home together is challenging.

Some find it helpful to emulate the experience of going to an office as closely as possible. That might be by doing things like only working during normal working hours, and going for a walk before and after work to replace the wind-down effect of a commute.

However, not everyone works at their best in this way all the time. Some find it easier to work in several smaller chunks through the day and evening, or get up late and sleep late, or take a 3-hour lunch break and extend the day. We want to be as flexible as possible, and reducing the number of meetings in the calendar helps to do that.

A popular idea in the retro was to have dedicated days each week when meetings were banned, and after a follow-up survey, we now have no team meetings on Tuesdays or Fridays. We’ll review this regularly to see if we’d like more or fewer days in the future.

We’ll keep reevaluating our ways of working. Whenever the option of working in the same space is available again, we’ll jointly decide what we want that to look like and how we can accommodate every individual’s needs. Though we’d love to be near each other again, we’ll probably never go back to working exactly how we used to.

Sharing and comments

Share this page

18 comments

  1. Comment by Erin Casali posted on

    Very interesting writeup and experiment, I've to say it's also really bold. I'd usually not advise to introduce so many changes all at once, but I'm glad it still highlighted positive outcomes.

    If I can add a couple of notes as someone that worked on a number o Automattic practices included the ones mentioned in the article you linked...

    The first thing is about email. You mentioned switching away from it and toward Slack and Docs. As the original author of the three speeds of collaboration model (realtime, async, stable) I'd invite to read also the model itself: https://intenseminimalism.com/2015/the-three-speeds-of-collaboration-tool-selection-and-culture-fit/

    The reason for this is that you might be missing the introduction of the "async" communication channel, and having just a realtime combined with a stable/operative one. It might not be super evident when starting, but an async channel would have a lot of long-term benefits — and I think shouldn't be a problem in a team such yours.

    The second aspect I'd highlight is that not everything has to be async'd. While a large part of the work should and could be, it's important to keep some elements of socialization and face to face (or, audio, if people prefer video off). Retrospectives are one activity that in general can be kept in realtime, with a hybrid approach where the collection phase is async, and the review phase is realtime.

    As for planning and alignment it's something that I usually suggest to do again with a hybrid approach, regardless of the extent (personal, team, or entire business units): have the collection part async (like an open form, suggestions box, etc) and then a first draft, followed by either a series of async drafts open for review (here's where an async speed channel is important) or a call if clarifications are needed.

    I've been doing this for years both inside Automattic, with public speaking, and consulting, so if you've any question feel free to reach out (Twitter: @Folletto).

    I also write on this topic extensively, so here's one of the bits that might interest you on text standups: https://intenseminimalism.com/2020/text-standups/

    Reply
    • Replies to Erin Casali>

      Comment by Xander Harrison posted on

      Thank you, Erin. It's great to hear from people with more experience of this.

      When it comes to the async layer, I hope we're in this position:
      "The tool processes are different from the team processes, and the team is willing to experiment and adapt."

      My guess was that necessity would cause an increase in async use of wikified Google Docs, as a clumsy version of a tool like Confluence. We didn't see much of that, but I suspect that's more because we're not in the habit of communicating that way than because of the limitations of Google Docs as a tool.

      One thing I'm considering is sharing some patterns of different ways of writing up, owning and soliciting opinions on different types of problem and decision.

      Reply
  2. Comment by Bev Smith posted on

    Really found this interesting thanks for sharing.
    In the Academy with course delivery punctuating the week it's great to think of new ways of working together

    Reply
  3. Comment by Sam Reeve posted on

    Great experiment - thanks for sharing. Glad that parts of government are pushing the boundaries of our ways of working.

    Working in new ways often requires better tools. Here's an asynchronous, non-push online debate platform that I found, and which I'm currently discussing with the DfE policy profession: https://www.kialo.com/

    Would be great to hear what other tools people favour here. I love Slack, but unfortunately we adopted MS Teams, which I think is worse.

    Reply
  4. Comment by Simon Dickson posted on

    I'm a former civil servant, and a former Automattic employee. It's great to see you embracing this opportunity to experiment.

    Asynchronous operation isn't the abandonment of all structure. You're replacing one set of expectations derived from physical presence, with another based on responsibility.

    As you discovered, clear definitions of responsibility are critical. You need clarity on what is to be done, by whom, and by when. But precisely what happens between now and then - that's where you have to step back, and trust your colleagues.

    Over a longer term, you also need to switch to working models which aren't so dependent on getting access to the person. Everyone must commit to documenting what they're doing; and tools must exist to make that documentation widely available. If I have a question, I need to be able to find the answer myself.

    At Automattic, we had live chat - IRC, then Slack - for chit-chat. But for anything of long-term value, we were expected to switch from chat to (effectively) a blog post. At long last, Automattic is working towards commercialising its in-house blog theme, known as P2, which adds some useful features; but any form of team site or shared resource might suffice.

    It's fair to say email was almost eliminated, for internal purposes. But most teams retained occasional team video calls; and met up in person 2 or 3 times a year.

    In my experience, the in-person meetings were where the big calls were made, communicated, bought into. If there's a way to make everyone jump together but asynchronously, I never saw it.

    Reply
    • Replies to Simon Dickson>

      Comment by Steve Messer posted on

      Hi Simon,

      Thanks so much for dropping in!

      > Over a longer term, you also need to switch to working models which aren't so dependent on getting access to the person. Everyone must commit to documenting what they're doing; and tools must exist to make that documentation widely available. If I have a question, I need to be able to find the answer myself.

      This speaks to our 'Make things open, it makes things better' principle, I think, and promotes better sharing within (and sometimes outside) a team.

      And I love that phrase about everyone jumping together, it does well to illustrate how alignment on our direction, our vision, sometimes relies on synchronicity.

      What was the biggest learning (or unlearning) for you?

      All the best,
      Steve

      Reply
    • Replies to Simon Dickson>

      Comment by Xander Harrison posted on

      That slower paced and considered documentation of what we're working on is definitely still a challenge for us. My reckon for this trial was that we'd see increased use of Google Docs, which is probably the most similar tool to P2 blogs that's easily available to us. I don't we really did, though. Some more cultural and tooling change is still needed!

      Reply
      • Replies to Xander Harrison>

        Comment by Erin Casali posted on

        You've highlighted an important point: there seems missing an async comms channel in the article highlights above. This is very important: it's hard to go really async without a channel / tool to manage such async information. I'm aware you might not have the freedom to install P2 or even just a WordPress multi-site instance, but I'd definitely put some reflection as you might be able to use some of the existing internal tools for this.

        For more details on the three speeds model, you can read here:
        https://intenseminimalism.com/2015/the-three-speeds-of-collaboration-tool-selection-and-culture-fit/

        Reply
  5. Comment by Andy Williams-Jones posted on

    We’ve adopted a “no meeting Wednesdays” in our team and it’s been working well for a couple of months now. Gives you time to focus and get stuff done.

    Our approach has also now been adopted formally by the rest of the organisation and we have a monthly “no meeting day”.

    Still a long way to go though. I have a gap of 1 hour in my calendar today. Back to back teams calls.

    Reply
    • Replies to Andy Williams-Jones>

      Comment by Xander Harrison posted on

      Thanks for stopping by.

      Have you seen a reduction in meetings from the no meeting days, or just a concentration on the other days?

      Reply
      • Replies to Xander Harrison>

        Comment by Andy Williams-Jones posted on

        Initially we did see an increase in meetings on Thursdays. This has eased now that we're using MS Teams more and having more conversational discussions across teams.

        Reply
  6. Comment by Alan Rider posted on

    Its a lot harder to stop meetings completely in a Department where you have to be contactable by other teams who don't work as you do. That's a challenge for flexible working patterns everywhere though. I have set a rule for my home working team that no meeting should last exactly an hour (or even exactly 30 mins). 45 mins max allows space between meetings to re-focus, and we have started standing up for video meetings so we are not sitting down all day long either.

    Reply
    • Replies to Alan Rider>

      Comment by Steve Messer posted on

      Hi Alan,

      Thanks for your comment, and it's good to hear that you're trying out new things too. Does standing up for meetings work well? How have your team responded?

      Thanks,
      Steve

      Reply
      • Replies to Steve Messer>

        Comment by Alan Rider posted on

        We are the DfT Digital Change and Adoption team so we do have a vested interesting in being open to this, so I've had no problems at all. We are trying to demonstrate to others that meetings are often detrimental to productivity and increase stress, even when working from home. That's a challenge to others ingrained working patterns, but then who said this was going to be easy? 🙂

        Reply
  7. Comment by Charles McDowall posted on

    You allude to three work activities, Synchronise/plan, engage and perform. Office based pre-covid working tended to blurr synchronise/plan with engage. This experiment seemed to downgrade synchronise/plan with obvious consequences.
    Getting a good regime of synchronise / plan which makes the most of technology to allow someone to take lead and pull it together, underpinned b the group interaction (meeting), engagement and individual contribution looks like the next distillation challenge. A somewhat fractal problem!

    Reply
  8. Comment by Brian posted on

    Great blog.Tools like MS teams, sli.do, Confluence / JIRA *should * mean less meetings, and more collaboration, at a time that suits. Not having specific meeting times, especially when meeting times collide; or appear over lunch times, because you have a space 😪

    The headline looks as if you stopped having meetings, and used emails instead, though. (A strange concept, email is getting very old hat) Would it read better as 'What happened when we stopped having meetings and stopped sending emails'

    Reply
    • Replies to Brian>

      Comment by Steve Messer posted on

      Hi Brian,

      Glad it struck a chord with you. Have you tried any experiments in your team? I found that blocking out time for lunch was a good place to start.

      Thanks,
      Steve

      Reply
  9. Comment by Peter Devine posted on

    Great to know that not having meetings went well and you prefer to use anything but email. I can see the appeal. I assume the absence of an app or website for the government to track and trace until recently or the utilisation of excel to collect data on the app once it was complete was not part of your responsibility. Otherwise I suggest you guys try to meet more often!

    Reply

Leave a comment

We only ask for your email address so we know you're a real person

By submitting a comment you understand it may be published on this public website. Please read our privacy notice to see how the GOV.UK blogging platform handles your information.