Idea: Slack/Github activity monitoring

Slack interactions are fully of interpretable events

Working for a distributed company has made me aware of an issue: employees can “disappear” too easily and no one notices. When employees have issues, there is no predetermined face-time to nip it in the bud. HR visits, employee gatherings, and good ol’ one-on-ones are easier to avoid. Distributed teams naturally focus attention where work is getting done and miss potential areas where employee satisfaction is not ideal.

Poor employee engagement could be pegged to a metric based on the interactions a person has per week.

I think you can solve for this without being creepy.

Its plausible that a basic observation of how users interact with one another in a public venue is a high signal for employee engagement. Using a Slack based company for example, if users are never active in any Slack channels, then they are most likely not participating in group discussions. This could be the result of many things, but for one, it could be a individuals sense of no longer feeling engaged by their coworker community.

Employee engagement viewed over time.

It is important to note that a person’s engagement could be interpreted many ways. A highly participatory user could be feel very disengaged. A non-participatory user could be very active in syncing up with channel activity, and therefore feel engaged. Based on these examples, public participation is not foolproof.

The public participation could be a strong metric when comparing a user against themselves, over time. For example, when a user begins at a company, their activity may be above normal, due to the high number of introductory engagements. As time goes on, an employee may shift into a participatory trend that resembles more alongside their overall behavior. Based on the corrected average, any significant veering away would be a event worth noting.

Commit history mapped against a user’s commit trend could surface potential employee-project connections.

The same analysis could be run on an engineering centric organization with a shared code repository. Whether Github or some locally Mercurial equivalent, the individual contributor trends could be interpreted overtime for employee-project match. For example, potential fit can be gauged based on an employees rate of contribution during certain projects.

This can be creepy from a management and HR standpoint.

User activity could signify user happiness.

To make this work, observed results should never be used for consequential results. Punishment or reward based on analysis would be counterproductive. Employees who believe their overall behavior is being monitored and tracked could feel untrusted. This form of analysis could be the cause for employees to actually feel dissatisfied.

The overall goal of this would be to catch the otherwise uncaught signals. The goal is not to monitor your employees. If something major changes, some structure should be in place to see that the a struggling employee doesn't simply fade away due to no longer being in the lime light.

Thanks to Edlyn Yuen, Gary Tsai, and Pippin Lee for ideas.