OSS work practices that are repulsive

“I believe in the principle that deep work and constant availability are repulsive concepts (in the magnetic sense).”
Tyler Mumford in comment 2 to this post.

This blogging thing really amazes me at times. I’m regularly left shocked at the serendipitous connections that form when writing posts. Take today’s post. I did a web search looking for the thread of an idea that had no relation at all to yesterday’s post. But of the millions of possible authors that could’ve come up in the search, the article I read first was by Cal Newport. The same Cal Newport as quoted in yesterday’s post. The two articles weren’t even from the same domain (BBC.com vs calnewport.com).

Not only that but the quote above from Tyler Mumford, in serendipitous response to Cal’s article, perfectly articulates what I was struggling to describe to close out yesterday’s post. Deep work and constant availability are indeed repulsive (ie mutually exclusive). Yet both exist within the activities performed using our OSS!!

Think about that for a moment.

There are some tasks that require constant availability (think about the NOC operators who have to respond urgently to any degradation in their network’s health).
There are other tasks that require deep work (think about the NOC operators who have to identify the root-cause of a really gnarly and catastrophic fault).

But the OSS user interfaces we build do little to separate them. The processes we design don’t consider their repulsiveness. Even the way we resource our OSS implementation projects suffers from this magnetic repulsion.

As an OSS implementer, I’ve always found it interesting that clients struggle to provide suitable expertise to steer the build, to ensure it’s configured precisely for their needs. I often quote the old parable of “you get back what you put in.” I still believe the saying, but there’s more to it than that.

An OSS implementation team needs significant input from the most knowledgeable end-users. They provide the local context, the tribal knowledge. But the most knowledgeable end-users are also most valuable at performing BAU (business as usual) tasks [assuming you’re transforming an OSS whilst still maintaining an existing network]. But I’ve rarely seen a client get the balance right between providing expertise to the “build” and “run” streams in parallel. Even rarer have I seen a client expert who can quickly task-switch between build and run activities. It seems to be much more effective if client expert/s can be seconded to work on the OSS project team with few BAU activities. Tyler’s quote above helps to explain why.

Build mode requires deep work, for the most part (eg coding, process design, solution architecture, data mapping, etc). Run mode tends to require constant availability, with a few key exceptions (eg network designs, root-cause identification, etc). The two require separation.

So perhaps the parable should be, “you get back what you put in and separate out.” 🙂