Balancing Work and Life with a 4-Day Week: How We Changed our Communication Culture

July 31, 2023
Balancing Work and Life with a 4-Day Week: How We Changed our Communication Culture

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 was 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 with 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 NASA – Not Another 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

  • See overall completion rates
  • evaluate blockers

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

  • Commenting and highlighting

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 audatious 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. NASA – Not Another Standup App is our largest Cloud app and we built it 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.

Author

Jaime Capitel
Content Creator

Social Share Buttons

Balancing Work and Life with a 4-Day Week: How We Changed our Communication Culture

July 31, 2023
Balancing Work and Life with a 4-Day Week: How We Changed our Communication Culture

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 was 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 with 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 NASA – Not Another 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

  • See overall completion rates
  • evaluate blockers

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

  • Commenting and highlighting

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 audatious 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. NASA – Not Another Standup App is our largest Cloud app and we built it 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.

Szerző

Content Creator

Megosztás