Balancing Work and Life with a 4-Day Week: How We Changed our Communication Culture
Our switch to a 4 day week has forced us to run resolution differently. From how we plan, test, design, and deliver, to how we meet and communicate. Documentation and async communication have become critical! In this article we’ll go over how we are shifting from back to back meetings to a more productive distributed collaboration culture… and productizing our process for other companies with similar challenges.
The 4 Day Week won’t solve every problem.
In December 2022, my company kicked off a trial of the 4-day week. Everyone loves it, but it hasn’t been easy: adapting to working 8 hours less per week without losing productivity is a heroic challenge we have gladly accepted.
Six months after the kick-off, we’re still making many changes to how we work. Indeed, I believe that the ability to question ourselves, to be constructively critical and open to criticism is what makes us a rock-solid team.
In this article, I’m going to give some tips based in our experience that can be helpful for any company considering a similar experiment. To do that, I’ll focus on the example of how we are tackling one of the main areas for improvement: our heavy meeting culture.
Tip # 1: Build Trust
The first time we ever talked about the 4 day week, we had a very open debate. We discussed whether it was something we actually wanted, why we wanted it, and how it would make a difference. Chris, our Co-CEO, even asked how we would feel if the trial were to be canceled.
I’ve already described this moment in an article about that debate:
As we insisted that we’d be fine yet sad to go back, we were silently committing to change. We’re going to try, we’re going to be the best version of ourselves, and we’re going to succeed!
In order to build trust, I think it’s key that everyone feels part of the decision. Each of us has been involved in picking up the exact model and the right processes.
We didn’t design a standard workflow for the entire company. Rather than that, we followed a bottom up approach with an end goal.
Even as we monitor productivity, we never compare teams or individuals. Metrics are there to help, guide, and coach. To make progress visible. To build trust and a shared understanding of where we should go next.
This is, for example, how we used Umano to help us with accurate story point estimates. As you can see in the picture, the average time spent per issue is proportional to how many story points we estimate.
Tip # 2: Get a realistic, no bull$*!t picture of the status quo
So yes, metrics are important. They help build an assessment of how the team is collaborating, what’s pushing us back.
But to have a realistic picture of how we work, there is nothing like a good look in the mirror.
And this is what we saw: we were having way too many meetings.
Essentially, we were still working as a traditional company that sits in the same office; not like the distributed team that we have become in the last 4 years.
If we didn’t change this culture, meetings were going to squash us.
Tip # 3: Break the status quo
When you have trust and a shared vision, you can afford to break stuff. Be the bull in the china shop!
This means different actions for different companies. In our case, we had to kill Zoom addiction. We knew that we’d gnaw at our fingernails while we fought withdrawal for the first couple of weeks. But it gets better over time!
In fact, we’re just starting to see that having less and shorter meetings is possible if we cover the groundwork upfront:
Always take meeting minutes. For group meetings, we use AI for full transcripts, post them into Confluence, and review them.
Create action tasks in Jira. This is an integral part of our follow-up process. Every decision and action item from a meeting is transformed into a task within Jira. This keeps everything traceable and allows team members to stay on top of what they need to do next without scheduling more meetings.
Enable asynchronous collaboration. The more we use tools like Confluence and Jira, and the less we use apps like Slack and Zoom, the easier it is for everyone on our team to know what's going on, even despite the different work schedules. One essential piece has been a tighter integration between Jira and Slack that makes issue comments way more effective.
Tip # 4: Build a central hub
Jira is at the very core of how we collaborate: our entire toolchain works because it’s connected to Atlassian’s productivity motherboard.
Tasks, decisions, action items… they’re all in Jira, ensuring full transparency and maintaining a full record of what we’re working on at any given time.
The issue with status updates
In spite of all our progress, we have learned that status updates are not easy to capture in Jira. We did try using Atlas, but we’re probably too small of a company for that.
We also looked around at standup apps that we could connect to Jira, both in the Marketplace and beyond… but we couldn’t find any that was good enough for our purpose.
In the end, we decided to build our own standup app, and we have just started using it!
The solution to our meeting problem has become a new product
I know that building an app to solve a problem for a 30-people company might seem like an overkill. But that’s how we built our success with SAML SSO back in 2012, so we’ve decided to stick wit it!
In this case, we believe that the app is very flexible and can be used to capture any type of scheduled feedback!
Essentially, you can benefit from the app if you’re interested in combining the following factors:
Regular, qualitative feedback. Since every user can be invited to the work stream, the app is a great way to document open feedback fairly, without HiPPos or biases.
A tight connection with Jira issues. The app makes it very easy to pick the Jira issues that you’re working on to comment on them.
Highlight milestones or blockers. Flag a problem, report any issues as blockers, or simply tell everyone that you’ve finally completed a critical task that was blocking others.
Combine async and sync comms. Since daily updates must be prepared in advance of the meeting, members who can’t attend will still be heard by the rest of the team. At the same time, meetings are way more effective since there is a lot more structure to them.
Three ways to use our standup app
We have designed the app to match different communication needs and preferences. As an illustration, I will offer three examples of how we’re using it internally right now.
Besides driving two classic agile ceremonies (daily standups and sprint retrospectives), our cloud team is also using the app to gather interest and discern whether they need to meet to discuss any topic in depth.
Example #1: Daily standup updates
Daily standup meetings are the #1 use case, and this is arguably what any other company will start with. There’s nothing too surprising here, besides the pleasant experience of having the standup seamlessly connected to your Jira issues.
Questions
Do you have any blockers?
What did you do yesterday?
What are you working on today?
These are the default questions – and we’re sticking to them.
Preferred feature
Picking issues from a shortlist
Documenting blockers and including them in our team summary has proven to be incredibly beneficial. It enables us to be more proactive in offering assistance to overcome any obstacles.
Example #2: Bi-weekly retros
As a team of agile teams, we’re working more and more towards a model where sprint retros help us share work externally and generate synergies.
The standup app is essential for documenting which epics and areas of work suffered from poor planning or hit any obstacle during the sprint, and spreading that knowledge through the company
Questions
What went well?
What should we stop doing?
Did we achieve the goal?
Preferred feature
It’s really simple, but I love the visibility of those comments on our different epics! Makes it very easy to have an overview of what everybody feels, and how it’s related to our ongoing work in Jira.
Overall completion rates are very helpful to look at also once the sprint is about to finish.
Example #3: Do we need to meet to discuss any cloud topics?
We have just restructured the number of recurring meetings that we do, and decided to drop a generic cloud meeting that was happening weekly.
However, our cloud Team Lead was concerned that we would stop discussing topics that affected all cloud developers. For that reason, he suggested having a stream in the app simply to gather potential topics of discussions, and then decide whether or not to run the meeting on that week.
Questions
Do you have any topics to discuss?
Preferred feature
The Team Journal in this case is just a great way to going through all the areas where the team is reporting that they want to share knowledge, learn from others, or skill up.
Conclusion
If you ever try it yourself, you’ll agree with me: A 4-day week can be very testing for your collaboration culture.
The scarcity of time creates stress on the existing processes, the cracks show – and then you know what needs to be fixed – even if you still don’t know how.
I don’t know how far we are from being entirely happy with our communication culture. Or when we’ll be able to say: each of our meetings is super productive!
But I know that we’re not sitting still. We’re making changes, we’re not compromising. And we’re even innovating and creating new products as we go.
The standup app is an audacious answer to two very different challenges. From a business perspective, resolution has embraced the strategic move towards the Atlassian cloud, and more specifically to developing apps with the Forge framework. The Standup App is our largest cloud app, and it’s built with Forge.
From a team perspective, we’re learning how to communicate asynchronously. Our standup app is essential in this collective training, as it allows us to build on top of Jira, and get better at working together.
Capture qualitative progress updates
Keep track of blockers, milestones, and highlights
Suggestions for Improvement:
Use real-world examples: Include actual examples of how the 4-day work week has been implemented in the company. How has the work schedule been divided? What were the initial hurdles and how were they overcome?
Share data and results: If available, share specific data about productivity before and after the implementation of the 4-day work week. This would strengthen your arguments and provide a more concrete understanding of its impact.
Expand on tools: Go deeper into the tools that you've used, explaining how exactly they've been used to facilitate asynchronous communication and collaboration.
Address potential problems: It might be helpful to address potential problems or issues that other companies might face when shifting to a 4-day week and provide suggestions on how to navigate these problems.
The good and the bad about a 4 day work week
To simplify a lot, the worst and the best about a 4 day week go hand in hand.
The worst: Having less times pushes you over the edge. Your processes show where they’re cracking.
The best: Since you can see the cracks, you also know where you must make progress.
Let me elaborate.
Having an extra day off is not a right we have conquered for eternity. If the company loses its competitive edge, we will probably cancel. And we would hate to do that.
Out of our deep appreciation for the remarkable work/life balance we enjoy, we have committed to the painstaking process of changing our habits, one day at a time.
But in order for that to happen, you first have to build trust.