Management by Experiment!

Within the same organization, the work varies and the nature of tasks differs. One person has to be available the whole workday in case any request comes in, another has to handle specific tasks either during or after working hours, and another has to get several tasks done at whatever time suits them.
In the workplace, one person needs to be present, receiving, handing off, reviewing, and double-checking, while another only needs to answer calls and reply to emails.
One person can do all their work remotely, and another has to do everything from inside the office.
Organizations and workplaces hold different specialties and all kinds of tasks, and yet almost all of them work 8 hours a day, five or six days a week!

On the Lenny Rachitsky podcast, the guest was the VP of Product at Shopify, who talked about several ways to improve the work environment, and about how he and his team regularly test new practices on their workplace and evaluate the impact on the environment, the employees, and productivity.

I won't go through the details of the podcast here. Instead, let's look at the idea of a manager being willing to experiment.
What do we mean by willing to experiment?
Experimenting is when a manager redefines the nature of work and productivity, taking a deeper look at whether an employee could do their job and tasks differently in terms of time, place, annual reviews, incentives, and everything else tied to the nature of the work.

In my humble opinion, the reason this doesn't get taken seriously is that it's heavy lifting for the manager 🤣.

Let's move on to some ideas that might make the concept clearer. In these examples I'll try to build a complete story with all its sides and details.

• If the team I work with had a task due in a month, and I gave them the option of working three weeks with extra hours and delivering the task early, in exchange for a week of vacation, would that make the team happy and the client happy?
• If I had an employee working in a region far from his family, doing certain tasks slower than he actually could, and I asked him to do the same tasks in four days in exchange for a longer weekend, would productivity improve?
• What if I had a team working on a set of tasks over two weeks (software development teams usually work this way), and there was one small change to how they work: finish these tasks in two weeks at most, meaning if you get them done faster, you get days off.
• What if I asked my employees to work remotely while keeping productivity high, and if productivity deteriorates, we all go back to the office!
• Evaluation criteria: should they be based on how many tasks got done? On discipline in arriving and leaving on time? On the number of happy clients, or on something else that fits the nature of the department's work?
• The list really goes on, and there's no counting the ideas you could try to improve your team's performance.

Why so much detail in each example? Because in my humble opinion, management by experiment first requires the manager to understand the details of the tasks and what the employee and the job actually need, so they can build the right incentive and the right change to the nature of the work, one that fits both the employee and the job. The employee ends up happy and motivated, and productivity is high and maybe even climbing.

It undoubtedly takes a manager who is sharp and brave. Sharp at noticing the details and building the right mechanism to make use of them and keep everyone happy, and brave enough to make the call and actually run the experiments. From what I've observed, some managers care a great deal about keeping everything exactly as it is so their reports stay completely satisfied with them. To be "a manager who runs some experiments", it's fine if someone gets upset with you someday 🤣

The ease of being an ordinary manager, one who shows up with the employees, everyone puts in eight hours of work, then heads home, is that nothing opens the door to accountability or questions, and nothing demands thinking about, evaluating, or improving the team's performance.
Improving the team's performance then falls on the employee alone. If performance improves, it's because the employee worked hard, and if it drops, it's because the employees are slacking and we need to hire 😂.

Before wrapping up, one practice I consider a mistake is applying what another team does to your own team, meaning implementing OKR and KPI and Scrum and so on... exactly as written in the book.
Building those strategies took those teams time to arrive at the idea in its current form, and they may well have changed or adjusted it after publishing it. So for a manager, reading about other teams' experiences should be treated the way a designer treats visual inspiration: you draw ideas from it before painting your own picture.
Every team in this world is a family with its own circumstances. It shares some details with other teams, but it certainly has details of its own that may not look like anyone else's.

It's good, and fun, to try a few things in how you manage and watch their effect, and your team can probably help by sharing what they need, what suits them, and what gets in the way of doing the job.
It's also good to rethink your team's criteria for success and build incentives that fit the nature of the work and those criteria.

Salam 🏃‍♂️