Picking up speed for the 4-Day Week
In the last two articles of this series, I explained how the 4-day week went from a crazy idea into an actual project, and how the Marketing team was the first to prepare for the trial. In this article, I go deeper into the details with the execution of our master plan, focusing on the many discussions, decisions, and changes that went into the preparation phase, and giving some details about the different approaches for every team.
Getting fit for a working marathon
In June 2022, my company decided to trial the 4-day week. We were in completely uncharted territory.
To use a sports metaphor: we knew that we wanted to run a marathon, but we also knew that we weren’t fit enough to finish it.
Why a marathon? Because our 100/100/80 model of the 4-day week means that we will produce at least the same, for the same salaries, in less time. Let me repeat: we will do more in less time.
Even the marathon metaphor falls short. After all, marathons end. But we are supposed to keep this momentum going over the months, and over the years. It’s a bit like living in a marathon, not just running one. But also, no pressure, we should enjoy the run, not suffer it.
We knew for a fact that we had to prepare for the 4-day week experiment if we didn’t want to get injured. Also, different athletes have different techniques and rituals: they don’t prepare in the exact same way for the big day. We needed to factor that in.
What did that mean for us? That we had to reject the idea of designing a standard workflow and push it to every team. The 4 teams in the company would have to get ready in parallel. Bottom-Up. Of course, some common foundations are needed: every runner needs running shoes, good hydration, a carbs based diet, and daily training. Every agilist needs to measure its productivity, document its work, and be able to handover asynchronously.
Questions for runners
Here are the questions that everybody, and every team, had to answer before jumping on the new, intensive week:
- How far can we run? We truly didn’t have any credible indicator of our productivity. But without knowing our endurance, there was no serious indication of whether we’d be able to finish a marathon.
- How much do we enjoy running? That the experiment would make us happier was only a hypothesis. Was there a chance that it would make us miserable? While unlikely, we also needed to track motivation and overall satisfaction.
- Are we talking so much we can’t go fast? As we saw in previous articles, we come from a meeting-intensive culture, and that can destroy anybody’s flow.
- Do we know what our team mates are up to? Ok, marathons are an individual sport. But think of cycling or any other team sport. Nothing happens without tactical coordination between the pieces. We needed to get there.
We need help → Fabia comes along in September
Chris and Björn were aware that they needed help for finding the best fitting methodological suit for every team. Not only because relying on the two of them for progress risked bringing the experiment to a halt; also, they have different personalities and it would be frustrating to have long and tedious discussions until they agreed on everything.
Fabia Wucherer joined the re:solution team on September 1st with the sole mission of helping us get ready for the trial. She had worked with many resolution employees in the past at a different company, including both Co-CEOs, and was well respected because of her skills as a process manager and controller. Also, at that time she had enrolled in university to study Psychology, which would be a great help given the topic!
This is what her job description said:
- Creating, rolling out, and monitoring team workflows, as well as productivity and performance metrics.
- Conducting longitudinal surveys. The first survey should serve as a baseline to gauge the motivation of the team prior to the experiment, while the later surveys are designed to monitor both the individual motivation and the potential conflicts with productivity and output.
- Researching existing models of the 4-day week and designing our own based on those best practices.
- Crafting a framework and a manifest capturing and detailing our model. The framework must include the coverage of the 4-day week and how it impacts vacation requests, bank holidays, overtime calculations, etc.
- Aligning to the company values and to the main requirements for the success of the experiment, including: a shared sense of responsibility for the sustainability of the company, close and proactive communication, as well as promoting each individual’s accountability in their areas of ownership and expertise.
- Identifying additional areas of improvement and recommending best practices for solving them. Some of those improvements were in already known areas. For example, a hot topic is increasing transparency & visibility across teams and individuals with the right amount of documentation.
Measuring the experiment: Metrics, happiness, output
Fabia was immediately drawn to the experiment and her important role as a facilitator. Admittedly, she also enjoys the privilege of being nosy without feeling too bad about it!
In her own words:
I see a very difficult balance with this project, and that’s why it’s so fascinating. To sum it up, we want to modify our behavior quite aggressively without actually changing our personality as a group of people that enjoy working together.
We have a small company where everybody knows everybody else, and decisions usually happen in domain-based groups rather than flowing top-down. What we want to have is the right balance so that we increase the visibility of what every team is doing without adding a layer of micromanagement, and without turning it into a robust process that slows us down. We also need to protect the current form of agility, which is the result of our ability to be spontaneous and flexible in how we react to the environment; while adopting the mentality of bigger companies in how we structure teamwork, handovers, planning, etc.
Metrics have a paramount role in this adventure: all of a sudden, the journey has data that can be read and deciphered. Metrics allow to diagnose whether things are going according to plan, and to capture signals of deviation and alerts before the plane is too close to the earth and a collision cannot be avoided.
The reason for using metrics is to guide people rather than control them or evaluate them individually. I obviously want to provide leadership a view of the numbers, but that’s secondary I would say. The number one goal is that every member of the experiment can assess the experiment as it’s developing, and that they can get their own feeling of productivity.
The hard metrics
We generate a lot of data, but the number of KPIs that we look at is minimum.
- Story points. As we’ll see, three of the four teams in the company (marketing, plus the two development teams) have adopted story points with the main goal of having a longitudinal view of average productivity and team velocity. We don’t believe that a sprint with 400 story points delivers more value than a sprint with 375 story points; but we do believe that a sustained decrease in the rolling average of story points completed per sprint signals a decrease of productivity that is worth examining.
- Customer satisfaction. For the support team, the productivity standard is none other than customer satisfaction. We’ll see more about that in their section.
Besides the core KPIs, Fabia has helped create a lot of different dashboards in Jira to assess the status of work for every department and team member.
Here is an example of some of the insights in the dashboard for marketing team members:
And below is a dashboard built with aggregated insights from our support tickets in Jira. Support insights are very popular at resolution, since they help management identify trends in the popularity of each app, which can in turn inform decisions on how to prioritize our marketing actions.
Additionally, we often go into Umano to gather more insights. And there’s plenty to choose from.
The soft metrics
To simplify, the hard metrics are the insights generated as we use Jira, and include variables such as team velocity, output, and so on. Overall, they are our new measure of productivity.
Soft metrics are captured with surveys designed and conducted by Fabia approximately every month, and they represent variables such as employee satisfaction, the subjective sense of productivity, and the commitment to the experiment.
Soft variables are the dependent variable
Soft variables are as important as hard variables. And they’re also more delicate. They say whether the experiment is successful for the people, not just for the business.
Soft variables are in a way more fragile (or more stubborn) because they are the dependent variable. We can decide to modify our behavior to remove waste, improve communication, and increase velocity… but what makes us happy or miserable is only an indirect result of our behavior… and the behavior of other people.
That’s why it’s so important to track the mood frequently and to have a good starting snapshot. Otherwise, we risk failing to capture signals of unhappiness early enough.
In Fabia’s own words:
Even if I know some people of the team from a previous job, I wanted to get to know the team better. Therefore I had a lot of 1:1s to understand their work ethic, what the team is expecting, what they love, what they dislike, etc.
Once 1:1 interviews had given her a complete picture, it was time for objective data.
The idea with the surveys was to measure whether the team feels productive AND satisfied.
Getting an actual baseline was challenging, because workflow adjustments were implemented step by step and not everywhere at the same time. At the time of the survey some teams (particularly marketing) were mid-way in their transformation process, and their answers to questions like: “will you be more efficient working one day less” or “how satisfied are you with your current productivity” meant something different than for those who still had to modify their workflow.
While the results are not perfect, we were able to identify a very high job satisfaction and to capture the self-image of the teams.
Ultimately, the surveys will be a key element for deciding whether the trial continues, or is suspended.
The continuous surveys will allow me to capture trends in key aspects such as satisfaction, felt pressure, flexibility, and commitment. Which means that with every survey the team is deciding whether we continue with the trial as well – not only the CEOs.
Gauging expectations for the 4-day week
Fabia conducted the first survey at the beginning of October, followed up by surveys during the trial every other month. We will devote a different blog article to them, but a bit of a spoiler is due!
One important question was about expectations.
What do you hope to get from the 4-day week?
Respondents could select more than one option – but overall, the 4 big hopes of the team were the options that you can see on the left of the chart:
- More social activities with friends and family, and more time for our own personal hobbies (86%)
- Being able to better handle other responsibilities that now have to be pushed to the weekend or that interrupt the week (71%)
- Becoming more productive and breaking away from the old habits, as described in this article (71%)
- More healthy habits, from spending less time in front of a screen to practicing sports (62%)
These four winners make perfect sense for me personally: they capture everything that I am currently doing. On my free days I:
- go swimming (health) or exercise at the gym
- do the weekly groceries and some additional errands around the house (other responsibilities)
- meet a friend, if they have time for me. And I’ve learned I need to schedule my social coffees in advance, because, surprise surprise! Most of my friends aren’t free on Fridays (socialize)
My way of working has changed completely from what I used to do less than one year ago, when I was writing less, procrastinating more, and not planning nearly enough! (productivity)
The trade-off between free time and stress
Besides knowing what employees would do on their re:st day, I also wanted to measure the impact on the remaining 4 days. Does everyone feel like they can cope, or is it too much stress? Do they prefer other options to advance their well-being?
Before starting, our team has a very solid image of the experiment: we think we can be more productive, we commit to the ongoing success of the company, assume that we will be more flexible, and don’t feel that much pressure about having to deliver in less time.
We trained for the marathon from July to November
With Fabia onboard since September, every team had the moral support and technical backing to audit their processes and get ready for the new way of working. In particular, she rallied all team leaders to ensure that the following aspects were covered:
- Necessary changes in Jira workflows and project configurations, along with any additional systems.
- Implementation of an agile methodology, usually Kanban or Scrum.
- Company-wide or team-wide meetings had to be rescheduled to either Tuesdays or Thursdays.
The rules to bind them all
On her own, Fabia was simultaneously drafting a manifest that had to detail the general rules that would apply to everyone — which proved substantially more difficult than expected. Since we didn’t really have any policies for managing employee time or requests for vacation days, having to set certain limits and restrictions felt like introducing a layer of red tape that wasn’t there before.
What changed in each team?
The marketing team = the Guinea pig
We have already devoted a full article to how the marketing team was the Guinea pig in the 4-day week experiment (hey, being the author has its own privileges!)
Not that we actually enjoyed working 4 days per week on an earlier day. But we started changing how we work in July, with 14-day-sprints including story points, and quarterly goals captured with Atlas.
The cloud team = the innovation lab
The cloud team at resolution is very unique for a number of reasons:
- It’s a distributed team. In addition to the core of German developers, there are two Brazilian colleagues, as well as a contractor from Slovakia. Plus Gerard, who works out of the Berlin office but is from Barcelona.
- There is no single product. The cloud team owns a portfolio of 18 apps, most of which are relatively small. That’s more than two apps per developer, and that’s counting the team lead! Usually, each app is developed by a single developer.
- Radical challenge in collaboration. With a lot of newcomers and no shared code base where every team can contribute, it was particularly difficult to align processes and practices.
The new workflow: kanban
The cloud team had already tried to work in sprints before and decided that this approach didn’t work for them yet. So they went for Kanban, with daily standup and weekly planning meetings.
We try to generalize as much of the apps as possible. Our daily standups and weekly planning meetings help the whole team identify opportunities for collaboration.
This generalized architecture helps keeping everyone on the same track. This is why it’s not very hard for another dev or myself to get into how one app works, because the mechanisms are relatively similar… and that’s hugely beneficial when every member of the team is off one day of the week.
Tobias Theobald, Cloud Team Lead
On top of that, they have implemented story points as a measure of productivity, also adopting their own interpretation of the Fibonacci scale
The next workflow: UI
The Cloud team was ready to adopt the 4-day week on October 10th… and at the same time far from having reached a stable solution. Three developers have teamed up with our UI designer to create a new app that will be the largest and most visual product by resolution. As Fabia says:
We’re picking up energy from these new products and novel approaches to collaboration. The company used to be very technical and targeted at admins, so the findings from the new workflow that includes Irina [our UI designer] will be then rolled out to the rest of the company.
The Data Center team: proud to be legacy
The legacy team develops a single, consolidated product with thousands of customers. The developers in the team have been in the company between 3 and 10 years, share a co-working space in Saarbrücken, and have a strong culture of autonomously deciding what to do next.
Chris Reichert, the Co-CEO, used to the be product owner for SAML SSO. But times are a’changing, and the new role has been delegated to a person who will have that exclusive focus.
Since the team has a common goal, works on a single product, and has offloaded the responsibility of supporting customers to a dedicated team, the road is clean for adopting Scrum. It’s not the first trial, but now the foundations look more solid!
We abandoned the process some time ago, when we were still the “Server” team, because our work at that time could not really be planned. We were implementing new features while doing (or assisting) support, which resulted in a lot of ad hoc changes. This made planning unpredictable and a waste of time.
Full Scrum – not that Marketing nonsense
In the last article we saw that Marketing had adopted a very light form of Scrum – like the vegetarianism of someone who eats fish, egg, and dairy, as well as the occasional KFC.
Compared to that, the legacy team is a level 10 vegan who doesn’t eat anything casting a shadow (yes, it’s a Simpsons reference). Here are the pieces to their workflow:
- Prioritization. The team uses the MoSCoW framework, which allows to rate user stories depending on whether they are a Must have (M), a Should have (S), a Could have (C), or a Won’t have this time (W).
- Complexity. The complexity is measured with story points using a Fibonacci scale with a legend.
- Urgency. To recognize that some feature requests may have important customers behind them, the team also factors in time criticality.
This factors are thrown into the cocktail mixer that is Foxly, an app by Jexo (recently acquired by Appfire), to decide what will go into each sprint.
The support team: JSM cuts it
When the company as a whole first discussed the 4-day week, the support team was always taken as the example of what could go wrong. Failing to help customers in a timely manner because they write a ticket on a Thursday afternoon was simply not acceptable.
But the team was already working in shifts to span the entire week and over most time zones. With the ability to choose the re:st day between Monday, Wednesday and Friday, it was very easy to come up with a structure of turns that ensured coverage on Fridays.
The other pillar that sustains the effort Jira Service Management, which the team has been using to communicate with customers since 2014 with excellent results. Below are the satisfaction averages for all customer tickets created last year over the customer portal:
The team, with currently 3 members, was born ready for the 4-day week. But right now Fabia is helping out in categorizing their work better.
Conclusion
On December 6th, the 4-day week trial started. Each team had made a ton of decisions to change how they worked. It felt different, but at the same time, there was a tension: we knew that we’d only started to scratch the surface of change.
Will it be enough to make it work? Will we stick to the changes, or revert back to the old habits of procrastination? Will we keep improving our practices and aligning better to agile methodologies?
It’s too soon to tell. In the next article, we’ll try to answer a different question:
Are we happier now?
Subscribe below to find out.
