Like any sane manager, I don’t pick an arbitrary bucket of tasks at the beginning of each week and declare “Finish these by Friday” and not care if it takes 10 or 100 hours.
Instead, we work with the team to do things like sprint planning with input from the team’s velocity. We target a reasonable workload assuming people are at their desks for a normal workday amount of time.
The problem is that for some people, individual velocity plummets when they go remote. Their estimates skyrocket because they either know their productivity is down or they think it will be easier to get away with if nobody can physically see them.
Obviously this doesn’t apply to everyone as I have some great remote teams, but I’ve also churned through some otherwise good engineers who were great in office but admitted that they just couldn’t focus at home.
Also, if you have anyone WFH with school age children then velocity drops come summer time like clockwork. We work around it and plan it in, but it’s another reminder that remote is hard for even the good remote workers.
Finally, not everyone’s work is 100% isolated and asynchronous. More often than not, people have to work together on things and be available to answer questions, fix things, or otherwise stay in the loop with updates. When people are disappearing for hours every day during the team’s core working time, this all gets slowed down immensely. I don’t care if two people who work together agree to work together at 3AM or noon, but the teams have to be present and available to cowork on things.
> I don’t pick an arbitrary bucket of tasks at the beginning of each week and declare “Finish these by Friday” and not care if it takes 10 or 100 hours.
I’d say that’s your first problem. Isn’t this the whole (popular) idea of creating a sprint, then not modifying the sprint as it’s ongoing?
> velocity drops come summer time like clockwork
I don’t see how this makes things harder to measure. The very statement of it implies you have measured it and know it to be true.
> Finally, not everyone’s work is 100% isolated and asynchronous
This is true of in-person work too. If anything, someone being at a desk means that the collaborative work is probably not getting done in that scenario.
Real world example: iOS team has one guy who gets it done in a week. Android team has two guys who get the same work done in two weeks. All of them work remotely and are known gamers.
Is work getting done or isn't it? How do you tell?
First off, don't judge on one task like that, there's just too many variables (for example: Maybe it's something built-in to iOS while Android requires writing a custom library or working around a broken API). Assuming this is a pattern, though, there's lots of ways to get more insight.
For example, next time, have the iOS guy work with the Android team, and vice-versa. It'll help cross-train and promote different ways of solving problems, but also give great insight into what's actually happening. This could just as easily apply to someone from the backend team or whatever.
Another way is daily standups. Is the Android team getting stuck on something for days a time? Are they constantly blocked by another team or bad process? Are they making progress on whatever tasks they are doing?
Looking at commit and PR history is another way to judge, provided it's someone who can code who's looking and judging. Is the amount of work accomplished for the velocity of check-ins reasonable? If people are consistently only doing a couple lines a day that's a good hint something's going on -- and is worth having a discussion about. I want to emphasize though this needs to be a pattern. Some of the hardest bugs I've fixed that have taken days to narrow down are basically a single-character change (< instead of <= for example).
Depending on the situation, it might be possible to get regular demos, eg: every few days. One way to do this is break down feature work into smaller iterative chunks/stories. Beware though, it's a thin line to becoming an obnoxious micro-manager.
Nevertheless, one does not get hired to sit there, they are hired to do a work. If a job’s output is totally unmeasurable/unobservable you probably shouldn’t have hired a person to produce that output.
Five years ago I worked on implementing a custom Bluetooth interface to act simultaneously as a Central and Peripheral for a smartwatch. The first several months of the work was spent reading the massive documentation and reading the driver source code and spec sheet and example programs from the chip vendor and getting the development environment set up. Some work has absolutely no real observable measurable output.
And the last several months? Hopefully you can see what I’m getting at. A job doesn’t exist if there is no observable output to it, at least not for long. Your manager would know if for those months you were supposed to be reading docs, that you were actually slacking off, because come time to implement the thing, you wouldn’t have been able to do it. Thus needing to spend another few months reading documentation, and there definitely is a cutoff point where if you have been reading documentation for many months and producing no output, you just get axed.
Incidentally, another reason for managers to be capable ICs. If your manager was getting frustrated with your speed at executing, he/she could always step in and “show you how it’s done,” or at least teach you about Bluetooth details themselves to spare you from having to spend time reading the docs.
Otherwise, they don’t really have a leg to stand on and it’s just shouting into the void like Vizzini yelling at his giant to climb up the cliffs faster.
Like any sane manager, I don’t pick an arbitrary bucket of tasks at the beginning of each week and declare “Finish these by Friday” and not care if it takes 10 or 100 hours.
Instead, we work with the team to do things like sprint planning with input from the team’s velocity. We target a reasonable workload assuming people are at their desks for a normal workday amount of time.
The problem is that for some people, individual velocity plummets when they go remote. Their estimates skyrocket because they either know their productivity is down or they think it will be easier to get away with if nobody can physically see them.
Obviously this doesn’t apply to everyone as I have some great remote teams, but I’ve also churned through some otherwise good engineers who were great in office but admitted that they just couldn’t focus at home.
Also, if you have anyone WFH with school age children then velocity drops come summer time like clockwork. We work around it and plan it in, but it’s another reminder that remote is hard for even the good remote workers.
Finally, not everyone’s work is 100% isolated and asynchronous. More often than not, people have to work together on things and be available to answer questions, fix things, or otherwise stay in the loop with updates. When people are disappearing for hours every day during the team’s core working time, this all gets slowed down immensely. I don’t care if two people who work together agree to work together at 3AM or noon, but the teams have to be present and available to cowork on things.