This post was last updated more than 1 year ago. Some content may be out of date.
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.
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.
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.
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:
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.
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!
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:
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.
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
These are the default questions and we’re sticking to them.
Preferred feature
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.
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
Preferred feature
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
Preferred feature
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.
Ez a bejegyzés több mint 1 éve frissült utoljára, a tartalom bizonyos elemei elavultak lehetnek.
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.
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.
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.
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:
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.
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!
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:
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.
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
These are the default questions and we’re sticking to them.
Preferred feature
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.
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
Preferred feature
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
Preferred feature
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.