The methods for hiring knowledge workers in the 21st century are heavily reliant on pre-digital mechanics. In the case of the hiring party, they will often publish a listing requesting an ideal skill-set. The process can be resource intensive for the employer and due to long-term changes in corporate initiatives, the employee's skill-set may only fulfill short-term organizational needs. This scenario results in product development and resourcing issues [4] due to a lack of on-hand, relevant talent, which is unable to fulfill changing corporate needs as well as employee disengagement caused by undesired responsibility changes. A 2016 survey of 1192 companies found that job postings took a 30 day median time to fill at a cost of $2000 per posting. [5] Additionally, there was a median 15% annual employee turnover rate and Industry standard recruitment costs for knowledge workers are ~20% of salary. [3]

The problem is exacerbated by the mechanics that support these activities. The current hiring process is heavily reliant on the posting and resume mechanic which is dependent on trust. The employer must trust the honesty of a candidate's resume and the candidate must trust the accuracy of the posting. From the candidate vetting perspective, there have been a few in-roads. These generally present themselves as a challenge during the interview process or a professional reference. Unfortunately, multiple studies [1],[2] have shown that performance in challenges during interviews have little correlation to long term performance of a knowledge worker. In software development, as an exception, Github works well if the candidate is working on an open source project (often not the case in a corporate setting). This also requires a secondary investigation. Background checks are also a common mechanic to verify employment history and income, which can be a necessity in a trust-based ecosystem

In the blockchain space, these issues become particularly evident. There are few qualified candidates and, likewise, very few people able to properly evaluate their skill-sets. The recent influx of new projects that ICO brings this to light. There is a lot of time spent by investors identifying whether project can be trusted and many projects have issues with successful launches because they are missing critical resources.

Building a Decentralized Workforce Platform

Moonlight takes an alternative approach to the mechanic used for project staffing, realization, and compensation to create a distributed workforce that is capable of fulfilling the needs of the current blockchain ecosystem while also tackling some of the issues presented in the conventional product development space as well.

In the project announcement for Moonlight, we outlined some of the fundamental goals of the project:

1. Accessibility of critical project resources
2. Verifiable organizational skill-sets
3. Improved project success rates

While these aren't the only goals of the project, they are certainly some of the more important ones. If you missed the project announcement, you can find it here.

Over the next few months, leading up to the formal whitepaper and ICO, we will be releasing a series of announcements that will provide some conceptual information about how Moonlight is being designed to meet the project's goals. These announcements are meant to seed the community with some of the Moonlight concepts in the hopes that we can fine-tune the project using community feedback.

In this article, we are going to cover some of the terms used in the Moonlight ecosystem as well as a concept for the Moonlight system token. We believe this information will be valuable for the community and helpful for understanding concepts presented in the next article which will cover the project definition and analytical project management components of the ecosystem. All of the concepts presented here will be presented in extended detail in the whitepaper.

Moonlight Terminology:

Organization

In Moonlight, organizations are the entities which generate content. An organization can be an individual or group of individuals. Organizations can also be made up of other organizations. They have the ability to generate tasks in the ecosystem and also resolve them.

Organizations can act in one of the following roles during task resolution:

1. Issuer: The organization that creates a task in the system.
2. Resolver: The organization that fulfills a task in the system.

 

Moonlight provides a number of mechanisms to track organizational competency:

1. Skills: Every task completed by an organization is published to the blockchain. The skills required for each completed task are logged to the organization and can be used to represent the domain-specific capabilities of an organization.
2. Reviews: After a task has been completed, the participating organizations (Issuer and Resolver) are prompted to review eachother. Organizational reviews are published to the blockchain. This review represents the overall quality of interacting with the organization.
3. Bid Accuracy: When acting as a Resolver, organizations place bids on tasks (see bidding). The accuracy of these bids relative to the actual completion duration are also logged as a tool to indicate the organization's bid quality for tasks. The skills associated with the tasks are taken into consideration when evaluating bid accuracy within the system.
   
   

 

In the figure above, we provide four examples of different organizational structures in Moonlight:

1. Individual: In this configuration, a single individual contributor operates as an organization. The competency of the organization represents the individual's capabilities.
2. Multiple Individuals: Multiple individuals can also be represented as a single organization. In this case, the skill-set of the organization is the sum of the skills of all individuals within the organization (since all the individuals are working as a single entity within the system).
3. External System: By interfacing with the Moonlight protocol directly, an external system can interact with the Moonlight platform similarly to an individual contributor. In this example, the organization appears to only operate as a task resolver. This mechanism also provides a level of automation to the ecosystem.
4. Multiple Organizations and Multiple Individuals: A single organization can also consist of multiple other organizations and individual contributors at the same time. This mechanic provides structure to large teams. In this architecture, organizations represent the sum of skill-sets for all their children. This example also exposes an anonymous individual within the organization. Anonymous users will be discussed in a later article.

Note: Interactions within an organization (How well a team works together in this case) are also represented in the system and will be discussed in more detail in the whitepaper along with organizational reconfiguration.

Task

A task is an atomic unit of work in the Moonlight ecosystem. Tasks have a value assigned to them (in system tokens) which is dependent on their value to the issuer. A task, can be comprised of any combination of activities or tasks.

 

 

1. Single Activity: In this example, a task is used to represent a single activity in the system. Required skills for the task are provided as well as a level of competence in each. A value (160 system tokens) is assigned to this particular task.
   
   Note: In some scenarios, an issuer may wish to censor sensitive information in the system. Moonlight provides a mechanic which allows issuers to create tasks in the system and match to resolvers with private skills that only they are able to use (and see).
2. Single Activity: See (1)
3. Multiple Activities: Multiple activities can also be represented by a single task. In this example, the user must complete multiple activities which require five unique skills in order to be awarded the value of the task.
4. Multiple Tasks: In this example, multiple tasks (each with their own value) are grouped together under another task. This mechanic facilitates larger projects. In this scenario, the total value of the task is the sum of the values of its child tasks. The resolver is awarded the value for completion of each individual task as they are resolved to the issuers satisfaction allowing contributors renumeration to be paid throughout the life of a project. Advanced task relationships (dependencies) as well as timing will be covered in detail in a later article.

Note: While Moonlight will implement a number of countermeasures to maintain the stability of system-token value (see System Token), it is recommended that issuers follow conventional project management practice when determining the scope of an individual task. By increasing the task size, issuers introduce uncertainty into their projects due to token volatility and estimation accuracy (which generally degrades with task size).

Activity

The work required by a resolver to fulfill a task.

Marketplace

A subset of the Moonlight ecosystem which provides organizations with tasks to resolve.

Duration

The amount of time in hours a task will take to complete. Unlike conventional systems, this is the 'real' time to complete task instead of the traditional FTE (Full-Time-Employee) hours.

For example:

Alex indicates that a task will take 3 days to close out and begins the task on a Monday. His 3 day estimate implies that the task will be completed at the end of Wednesday.

This mechanic is more effective than the FTE estimation method which assumes an organization is fully allocated within the system. This will be covered in more detail in a later article.

Matchmaking

In Moonlight, issuers create tasks and identify skills which are required for completion. Additionally, issuers may assign a level of competency to the skill to further define desired qualifications. Like the required skills, segments of the task definition may also be censored from public view.

Note: Organizations are incentivized with system tokens to audit the tasks of others and can recommend additional skills, improvements to the task definition, and modifications to the value.

A matchmaking algorithm is built into the Smart Contract to provide resolvers with task recommendations based on skillset. Access to the Smart Contract version of the matchmaking protocol will be publicly defined and available. Core Moonlight applications (such as the marketplace) will use an off-chain version of the algorithm for performance. Developers wishing to interface with the ecosystem will have access to the matchmaking algorithm through the public API. While an on-chain match-making algorithm will be available, use of the off-chain version is recommended unless access is being made via another smart contract.

Upon task completion, both the issuer and resolver must provide a review of the other. An organization's experience gain has a scalar applied to it which is correlated to the review they received. Once the review is completed, the resolver's record in the system is updated to represent the skills required to complete the task. Reviews (in addition to the skills) are stored on the blockchain for verification and reference by others.

Bidding

Once matched, resolvers may bid on the task. In Moonlight, bidding is different from the conventional contract-hire mechanics. Instead of bidding with a price, resolvers bid with a task duration. The issuer is then able to make the final selection for who will become the resolver. This mechanic is more aligned with conventional project management techniques.

By increasing the value of a task, the issuer is able to incentivize more organizations to bid on the task. The increase in bid competition promotes more competitive bids (lower durations), which implies the organization will assign priority to the task. The organizational competency mechanics (see organization), specifically the reviews and bid accuracy, provide controls against organizations presenting unrealistic bids.

Requests for a bid can also be made to specific organizations. Automated resolver selection will be covered in a later article with additional details available in the whitepaper.

Note: Being a match for a task is not required to place a bid on a task.

System Token

A system token is used on the Moonlight platform as a representation of resource utility as well as a representation of task value for project tracking purposes. It can be exchanged for the completion of tasks in the Moonlight ecosystem. While the token mechanic for Moonlight has not been fully defined, we can provide an example of one such mechanic for review by the community. The mechanic defined below is designed to provide stability to the intrinsic token value. While this does not consider speculative token value, it does reduce the price volatility, which is considered harmful to the Moonlight ecosystem which relies on a stable task market.

In Moonlight, we apply two fees:

1. A task completion fee (5% of the task value)
2. An additional fee if payment or receipt are made using a non-system token (10% of the task value)

The Moonlight system token then grows in total volume proportionally to collected system fees to maintain a stable intrinsic token value over the life of the moonlight ecosystem. Grown tokens are claimable by token holders at a quantity proportional to their holdings.

Below, you will find the results of a simulation (100 replicates) representing this fee mechanic. Some of the assumptions are intentionally conservative. Others are approximations:

Assumptions:

1. Total individual contributors in the market:
   - Normal distribution:
   - Mean: 500 contributors
   - Sp: 100 contributors
2. Total contributor growth rate:
   - Normal distribution:
   - Mean: 0.3%
   - Sp: 0.02%
3. Total market contributors using Moonlight:
   - Sigmoid approaching {1}
   - Half-life (Normal distribution):
   - Mean: 365 days
   - Sp: 40 days
4. % of tasks payable using non-system tokens: 75%
5. Task values:
   - Poisson:
   - Median: 160 (approx. 8 hours net income of U.S. laborer in USD)
   - Lambda: 1

Figure 1: A representation of the in-system individual contributors over time (2 years). The figure above represents a very conservative initial market assumption (even when only considering 'technical' individuals in the blockchain space). Moonlight is designed to support non-technical individuals as well.

Figure 2: Represents the daily fees for system use.

Figure 3: Represents the cumulative fees for system use over an 2 year period.

 

References

[1] (http://www.nytimes.com/2013/06/20/business/in-head-hunting-big-data-may-not-be-such-a-big-deal.html)
Bryant, B. (2013). In Head-Hunting, Big Data May Not Be Such a Big Deal.

[2] (http://journal.sjdm.org/12/121130a/jdm121130a.pdf)
Dana, J., Dawes, R, & Peterson, N (2013). Belief in the unstructured interview: The persistence of an illusion: Judgment and Decision Making, Vol. 8, No. 5, pp 512-520.

[3] (https://www.topechelon.com/blog/placement-process/typical-placement-recruitment-fees-average/)
Matt Deutch. (2017). The biggest Recruitment Fees and How to Collect Them

[4] (https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf)
Project Management Institute. (2017). Pulse of the Profession: 9th Global Project Management Survey.

[5] (https://www.shrm.org/hr-today/trends-and-forecasting/research-and-surveys/Documents/2016-Human-Capital-Report.pdf)
Society For Human Resource Management. (2016). 2016 Human Capital Benchmarking Report.