There are multiple reasons, and here is one of them:
Imagine yourself as a boss. How would you check whether your employess are doing the stuff you pay them for, or just taking your money and slacking? (Because there are many people who would enjoy the opportunity to take your money for nothing.)
This depends on the work. Sometimes the outputs are easy to measure and easy to predict. Suppose your employees are making boxes out of cardboard. You know how many boxes per hour can the average worker make, so you have a simple transformation of your money to the number of boxes produced. If someone does not produce enough boxes, they are either incompetent or slacking; in both cases it would make sense to replace them with someone who will produce enough boxes.
This is the type of work that would be safe to let people do remotely—as long as the same amount of boxes is produced, you get the value you paid for—although there may be other reasons that make it difficult: transportation of the cardboard and the boxes, or maybe if a machine is needed.
But imagine the kind of work like software development. To the eternal frustration of managers, the output is hard to measure. Both because of inherent randomness of the work (bugs appear unexpected and may take a lot of time to fix), and because the people who supervise the work are usually not programmers themselves (so they have no idea how much time “writing a REST controller which provides data serialized in XML format” should take—are we talking minutes or weeks?). Different people have different strong opinions on what quality means, but it is a fact that some projects can grow steadily for years, while others soon collapse under their own weight.
Having this kind of work done remotely, how do you distinguish between the case when the employee solved a difficult problem, fixed someone else’s bug, and spent some time preventing other bugs happening in the future… and the case when someone did some quick and dirty work in 2 hours, spent the remaining 6 hours watching Netflix, and afterwards reported 8 hours of work? Trying to impose some simple metric such as “lines of code written per day” is more likely to hurt than help, because it punishes useful legitimate work, such as designing, or fixing bugs.
Making the people stay in the office guarantees that they will not spend 6 hours watching Netflix. They may do good work, they may do bad work, or they may find ways to procrastinate (e.g. watch YouTube videos instead). But at least, there is a long list of things they can’t do.
It seems like a problem of trust, but on a deeper level it is a problem that you can’t even “trust but verify” if you can’t actually verify the quality of the output. So you have to rely on things like “spent enough time looking busy”, which sucks for both sides.
Note that this sort of inspectability is, in principle, accessible for remote work; you could have software that captures what’s going on for each employee’s screen (or webcam), and either randomly sample it or programmatically check for long periods of inactivity, or attempts to fool the system, or so on.
Note that supervision of complex knowledge work is _ALMOST_ as difficult in an office. There’re plenty of ways to slack off while physically present—watching netflix is out, but that’s not the risk. Reading Less Wrong all day looks like work, at first glance. And the solutions are the same. First,
the people who supervise the work are usually not programmers themselves
is simply a mistake. At least in the big tech companies I’ve looked at, managers were almost always engineers before they transitioned to the dark side. And there are 1-2 levels of management that bridge the evaluations from the line-level “able to evaluate daily work of programmers” to the senior management “able to evaluate a team’s business-impact output”.
Second, as long as you have SOME employees who are actively invested in the work, they’ll tell you who they want to work with and who they don’t, and why. This isn’t perfect, and some will lie or misinterpret things, but it’s enough of a pointer for managers to more actively look into.
There are multiple reasons, and here is one of them:
Imagine yourself as a boss. How would you check whether your employess are doing the stuff you pay them for, or just taking your money and slacking? (Because there are many people who would enjoy the opportunity to take your money for nothing.)
This depends on the work. Sometimes the outputs are easy to measure and easy to predict. Suppose your employees are making boxes out of cardboard. You know how many boxes per hour can the average worker make, so you have a simple transformation of your money to the number of boxes produced. If someone does not produce enough boxes, they are either incompetent or slacking; in both cases it would make sense to replace them with someone who will produce enough boxes.
This is the type of work that would be safe to let people do remotely—as long as the same amount of boxes is produced, you get the value you paid for—although there may be other reasons that make it difficult: transportation of the cardboard and the boxes, or maybe if a machine is needed.
But imagine the kind of work like software development. To the eternal frustration of managers, the output is hard to measure. Both because of inherent randomness of the work (bugs appear unexpected and may take a lot of time to fix), and because the people who supervise the work are usually not programmers themselves (so they have no idea how much time “writing a REST controller which provides data serialized in XML format” should take—are we talking minutes or weeks?). Different people have different strong opinions on what quality means, but it is a fact that some projects can grow steadily for years, while others soon collapse under their own weight.
Having this kind of work done remotely, how do you distinguish between the case when the employee solved a difficult problem, fixed someone else’s bug, and spent some time preventing other bugs happening in the future… and the case when someone did some quick and dirty work in 2 hours, spent the remaining 6 hours watching Netflix, and afterwards reported 8 hours of work? Trying to impose some simple metric such as “lines of code written per day” is more likely to hurt than help, because it punishes useful legitimate work, such as designing, or fixing bugs.
Making the people stay in the office guarantees that they will not spend 6 hours watching Netflix. They may do good work, they may do bad work, or they may find ways to procrastinate (e.g. watch YouTube videos instead). But at least, there is a long list of things they can’t do.
It seems like a problem of trust, but on a deeper level it is a problem that you can’t even “trust but verify” if you can’t actually verify the quality of the output. So you have to rely on things like “spent enough time looking busy”, which sucks for both sides.
Note that this sort of inspectability is, in principle, accessible for remote work; you could have software that captures what’s going on for each employee’s screen (or webcam), and either randomly sample it or programmatically check for long periods of inactivity, or attempts to fool the system, or so on.
Note that supervision of complex knowledge work is _ALMOST_ as difficult in an office. There’re plenty of ways to slack off while physically present—watching netflix is out, but that’s not the risk. Reading Less Wrong all day looks like work, at first glance. And the solutions are the same. First,
is simply a mistake. At least in the big tech companies I’ve looked at, managers were almost always engineers before they transitioned to the dark side. And there are 1-2 levels of management that bridge the evaluations from the line-level “able to evaluate daily work of programmers” to the senior management “able to evaluate a team’s business-impact output”.
Second, as long as you have SOME employees who are actively invested in the work, they’ll tell you who they want to work with and who they don’t, and why. This isn’t perfect, and some will lie or misinterpret things, but it’s enough of a pointer for managers to more actively look into.