Measuring the Output of Remote Teams
Last year the whole world was forced to switch to working from home. It was an acceleration of the trend of working remotely. One of the most common questions managers ask when this switch happened: "How can I know my people are working". A lot of them have the wrong (in my opinion) assumption that:
- If you are in the office, you are working
- People are always searching for a way not to work.
"Are people working" is the wrong question. The right question is, "are we delivering" and "are we working on the right thing". I don't care if the engineers on my team only work 1-2 hours a day, as long as they deliver.
In an office environment, we are often blinded by the input we see - for example, "Rado is always in front of his laptop, he must be working a lot". Even worse, if someone is very "loud" during standups and meetings - they must be very knowledgeable.
The usual advice people give is to "Measure output, not input".
However, this isn't very actionable. What is the output? What is the correct output? Do I get the output of an individual or a team?
Pre-conditions
I have found out that to measure the output of a team, you need the following pre-conditions:
- Have an anchor or baseline
- Create a rhythm of work for everyone - all sprints start and finish on the same date.
- Have clear expectations about the expected output
- Enable people to work independently by removing blockers and dependencies between people (collaborative single-player mode)
Not having clear expectations is easier to hide when you're in the same office because people assume other people know the context.
How this currently works at Product Hunt
In Product Hunt, people are grouped into teams, and they work in 2-week sprints. Every team sprint starts and ends at the same time. This creates a rhythm of work.
Tasks in the sprint are split in such a way that developers can work in single-player mode.
We encourage people to open pull-requests and deploy to production every 1~2 days with feature flags. A single task can have 2-3 or more pull-requests.
We have weekly check-in on sprint progress - is it on track or not.
With this process, it is easy to spot if a task is stuck and possible to quickly correct course. I have very rarely seen cases where someone is not working. Usually, the task is stuck because of a scope issue or technology challenge.
Overwork
What I have often seen in a remote environment is people overworking. Because I don't know if someone works 2 hours or 12, it is easy to hide overwork. This makes it difficult for this individual to set the right expectations and it hides problems with task scoping.
The way to solve this is to trust the team. Don't blame people when they are late, and don't award people who overwork.
I often say:
It is not a problem to be late. A problem is - not telling me you will be late the moment you realize it.
Conclusion
I have been working remotely for about a decade, and I can't see myself ever measuring people's hours. I care that people don't do many extra hours, though, because this is unhealthy and stems from bad planning.
Being in an office often hides problems with the process. You need 10x more process for remote sensing initially, but, with time, it scales better than being at the same place.
If you have any questions or comments, you can ping me on Twitter.