We now have a good reason to ask, in earnest, a question that’s been asked for theoretical reasons before. “Could what we call ‘office work’ be conducted in a purely remote or work-from-home (WFH) context?” We might even be approaching the point where we ask whether many of the jobs that we see as requiring workers-in-a-workplace could be done in a different way. I’ve diddled with modeling, and found some interesting points.
Office work is a mixture of task-specific behaviors, and it appears that we can safely group the behaviors into two models. One of the behaviors is the work-with-this model, where a worker interacts with their assignment and its associated data. The other is the work-with-people model, where the worker collaborates with other workers to achieve a collective result. We can extend this to the overall workforce by adding a third model, the work-on-this model, where the task involves direct physical interaction with something, a product, for example. That involves robotics, and it’s a topic for a later time.
It’s pretty obvious that work-with-this tasks could be conducted anywhere that the task-related data could be made available, in a secure and governance-conformant way. When I blogged about the broad impact of COVID on tech HERE, I discussed ways of providing tech support for the enhanced data delivery that the work-with-this model would require. There are other issues to address for that model, which I’ll get to below.
The work-with-people model requires that we support not an exchange of data, but rather facilitate a manner of human interaction. The interaction could be pairwise or group, casual and tactical or formal and scheduled, built around a context or carrying its own in-conversation context. I talked a bit about the collaborative channel in the blog referenced above, but again there are things about the model beyond the technical facilitation that need to be addressed.
The biggest issue we have in remote/WFH work is that we have work practices that have evolved with the expectation that the work, the people, and the interactions take place within a facility, meaning that the “office” becomes a place where we collect all the elements of “work”, so our work practices presume that we have in fact collected them. My suggestion has been that to make remote and WFH stuff work, we’d need to virtualize the office, meaning create a framework within which we can work via technological coupling rather than through physical colocation.
The work practice issue is the one I want to talk about here. We could spend an enormous amount of time, money, effort, creating a perfect virtual analog of a physical workspace. Decades ago, when collaboration of this sort was called “computer-supported cooperative work” or CSCW, Bellcore did an ambitious project that tried to do just that, including the notion that because people could pass by a cubicle and glance in to see if the person was busy, they’d support a “glance” as a momentary activation of a webcam to allow someone to virtually check the status of somebody. It failed, in no small part because people didn’t believe the camera was activated only for that purpose, so they covered it. The point is that sometimes you have to jigger the problem in order to solve it.
What would an ideal work practice for remote/WFH look like? Let’s start by presuming that it wouldn’t have developed the same way as office work practices would, and then look at optimal goals, working from them to remote practices.
Most work will be a combination of our work-with-this and work-with-people, meaning that workers will have individual tasks that they perform largely on their own, interspersed with collaborative relationships. It’s not difficult to see that if this is the case, then the optimum approach would be to manage the workflow so that periods of collaboration were concentrated into specific episodes, leaving the worker independently pursuing their own tasks in between. This would reduce the risk that collaborative needs that couldn’t be easily scheduled would hold up the progress of workers. WFH or remote work, then, is substantially optimized through project management. To do that, we have to look at the nature of task-related interactions.
“Let me know if you have questions” is a popular ending to an assignment, but I submit it’s an example of a “colocation” presumption in work practices. Rather than provide full and detailed information, we take a stab and tell the other person to come back with questions. That might even be smart, if we could assume that in most cases the other person wouldn’t have questions. The problem is that it’s not compatible with WFH/remote work, because “letting me know” now involves a more complicated scheduling process.
Not an impossible one, though. The mistake I think Bellcore made was thinking that the casual interactions had to be supported for the practice not the goal. We could probably address a lot of the “let me know” interactions through an email. We could address them within the context of some project management software that provided for collaborative messaging. Casual “let-me-know” collaboration, then, can be supported remotely without too much effort, as long as we make sure that we keep the solution casual too.
“Let’s get together” is an example of what might be considered extemporaneous meetings. Something has come up (possibly one of those “let-me-knows”) that suggests that multiple people need to be level-set on something, or need to collaborate in dealing with something. These extemporaneous meetings may need to reference something, create something, or simply communicate something. That means that we need to accommodate the distribution and sharing of collateral information, which might mean application access, sending a document, collaborating on a document, etc.
This kind of collaboration marks a sort of boundary. It’s likely that casual collaboration is well-supported via a generalized set of tools. It can be integrated with project management tools already in use, if those tools support the workers involved in remote work and also support casual messaging, but it’s probably not useful to acquire and socialize new tools for this purpose. The get-together collaboration might make a tool worthwhile.
A collaborative tool is most likely needed/justified where the team working on a project is fairly homogeneous and sharing the project’s work over a fairly long period. This permits the tool to be specialized to the work, which makes it more likely to be accepted by the team members, and to augment productivity. You could probably say that get-together collaboration either justifies a specialized tool for collaboration, or it should be considered a target for general WFH/remote work augmentation.
The question here is the uniformity of the group, and as an example let’s take software development teams. These teams have a common mission, their work is a classic mix of on-your-own and reviews, and all the workers in the group are likely to have a similar frame of reference and similar data/application frameworks that drive both their individual work and their collaboration. There are many software project management and code review tools, and even organizations that don’t use them might find them helpful if the team members were suddenly transported to remote/home locations.
“Set up a meeting” is the last example, and this is obviously a formalized collaboration. These meetings are scheduled, must-attend, and significant in their role as part of the overall project workflow. Just as the “get-together” meetings, these meetings may be important enough to justify special tools just to create/support them. Since nearly all companies will use this approach for cross-organizational coordination, it may make sense to look to more general project management tools. Again, this is most likely to be successful if the tools are already in use, but if there are enough of these kinds of formal cross-organizational collaboration activities to support, the broader use may justify a new software tool to provide that support.
Overall management of WFH/remote workers engaged in common project activity seems to work best if the project is organized as a series of regular meetings (no more than weekly, no less than biweekly, according to companies I’ve chatted with on the topic). The greatest success comes if these meetings are scheduled on Mondays, so the meeting level-sets for the week’s activity. Again, best practice seems to be to divide the meetings into three segments—review of scheduled completed tasks, reviews of longer in-progress task status, and problem review.
The most important thing about task-oriented project management as a WFH/remote work tool is to be sure the tool provides integration of collateral in a useful way, which is where the mashup-and-panel stuff I cited in the blog I’ve referenced above comes in. Project management for efficient WFH and remote work, but WFH in particular, needs to be flexible enough to schedule things that used to be extemporaneous, to organize and optimize workflows to minimize the need for interaction, and to integrate with things that can present and organize collateral. If we have all of that, we can make WFH very efficient indeed, enough to justify looking at it as an alternate to “the office.”