The core advancement of the Internet was the capability to move information very quickly across a decentralized network of nodes. That advancement was predicated on the development of protocols like HTTP, SMTP and Bitcoin that codified how such data should move to accomplish our tasks.
Despite this level of progress, we continue to lack the ability to request labor over the web using a standardized protocol. It’s not for lack of trying. Elance was one of the first attempts to aggregate freelancers online through a bidding marketplace, all the way back in 1998. Amazon’s Mechanical Turk was launched in 2005 to create a processing infrastructure for work units that could be easily handled by humans but were difficult for computers to process. Newer startups like TaskRabbit have tried to take the lessons of these pioneers and make labor marketplaces more approachable.
We need to do better than this if we want to create a more globalized and efficient talent system. Today, seeking out and hiring workers remains one of the most onerous tasks for many companies, from startups to the largest Fortune 500 corporations. Why shouldn’t requesting work be as easy as requesting a page from a web server, or moving money through the web with bitcoin? That sort of simple protocol is what I am proposing here.
Sketches Of A Labor Protocol
While many labor tasks can be complex and consuming, we can simplify our thinking by breaking the process of work into three different types of information. Inputs are all the data, information, and knowledge that a laborer needs to accomplish a task. The output is the desired work product. And in between, there is some sort of communications feedback loop to connect the worker to the requestor to handle clarifications or to send other messages.
Essentially, we are connecting workers (“servers”) to employers (“clients”) together using a medium of exchange. Requests for work could be handled in a way not unlike DNS – our communications stack could route our request as it learns more information and gets feedback from the network. This allows the network to remain decentralized and flexible, while adapting to changes in labor.
Let me give an example. Let’s say you have an article you want to publish, but first you want it revised by a professional editor. Editors, who could be anywhere in the world, are available on this labor network and might be independent, or part of a larger “association server,” which aggregates similar types of workers. I can send a request out over the network with a payload that includes the text of the article, the language of the article, the type of work I am looking for, the timeline for editing, my price, my quality level, and any additional information I feel is relevant (I’ll talk about type and quality more later). We connect to several central labor servers, learning where such editors are located and what their prices will be. When our software finds a match, we establish a connection and the work is completed on the schedule I defined.
To define work types, our protocol would need a type system similar to MIME to reduce “work” into fundamental units, while allowing our classification to adapt to new types of work as appropriate. Laborers could then register their qualified work types with open work servers to federate their availability across the network.
Another issue here is developing a reputation system that would ensure that both buyers and sellers have the information needed to make careful business decisions regarding work quality. One option may be to save work outcomes as a sort of “blockchain,” so that others can see the entire history of work that was processed and requested by nodes in the system.
One problem that existed for years in this sort of design was around payments – how could we ensure that remuneration would arrive once the work was complete? Now, with the advent of Bitcoin, we have the underlying protocol necessary to be able to both guarantee availability of funds, and to ensure that work is compensated once complete.
These are the building blocks for a work protocol. Like most protocols, simplicity here is a priority, as is keeping the possible states to a minimum. From here, we can build ever more complicated work arrangements, by composing work units together, by allowing new kinds of servers to offer services unavailable through the protocol (buffering, scheduling, etc.), and by allowing the client software to interact through the network in an open way ready for experimentation.
Characteristics And Questions Of The Labor Network
There are a number of lessons we need to glean from the first generation of labor marketplaces in order for a labor protocol to be effective.
First and foremost, we need to develop a robust set of classifications to handle outcomes consistently. Unlike HTTP, where we have basic status codes like 200 and 404, this work protocol needs to have a significantly greater spectrum of statuses to match the more complex outcomes of work.
We have learned repeatedly from initial labor marketplaces that most work requestors hate the bidding process. This is why companies like Uber take the choice away from you – ultimately, a taxi has to go from point A to point B, and as long as the driver can do that, the requestor shouldn’t really care who the driver is. The price of that taxi ride is already locked in.
However, that doesn’t allow laborers to choose their prices, which is inflexible to the vast types and quality of work that could be requested on the protocol. The way to avoid this is to allow customers to set the price and quality for work, and allow the network to do its own routing. That could mean that there are no workers available, much like accessing a website might return a 404 error code. If this happens a lot, the client software could be designed to suggest prices based on historical data. Regardless, both employees and employers should be able to independently set their rates, and work should flow most efficiently for the level of quality a requestor desires.
Conclusion
While this was an imaginative sketch of a potential technological system, many of the ideas behind it already exist in areas like supply chain management and on-demand workforces. Indeed, one possible interpretation of this is that we are simply converging on the next stage of the labor economy, one that is more Internet-native than LinkedIn or oDesk.
There are, of course, key concerns to be addressed. Many of these are policy related, such as issues of health insurance, taxes, retirement savings, etc. Others are more in the domain of the protocol. How do we handle complex work where descriptions of the work are dense? How can we handle complaints? How do we ensure that the protocol allows workers the freedom to be innovative and creative, within labor classifications that are designed for machines? There are no easy answers to these questions.
Nonetheless, an efficient labor network would allow both employees and employers to get work done more easily and efficiently while reducing barriers. Much as how the Internet allows information to travel faster, and Bitcoin allows payments to be handled easily, a work network could allow us to build more liquid economies with stronger employment prospects. Hundreds of new businesses could be built on top of such a protocol. And that might be just the kind of technology that can make the world a more equitable and profitable place for everyone.
Image via Shutterstock
Comment