Blender Corp was in dire need of improving its approach to how it hired, fired, and managed company employees. A model was developed, allowing them to simulate the impact of various measures.
The above web app is that model, running in your browser, so you too can play with the parameters and see how it plays out. Blender Corp is of course a fake company, and this simulation would naturally be a simplified view of the world, but still.. It was a fun little hobby experiment I enjoyed developing, so I hope you enjoy playing with it.
First some introductions to what you see and what the parameters control:
At the top left is a building, with workers coming and going. The colors of the workers represent the overall distribution of employee skill level. Blue is for the A-players, those whom are especially good at what they do. Then we have green for B-players; These are good workers, above average in skill. C-players are the average, represented with a yellow color. Then we have the less good employees, the D- and F-players. D-players (red) have some skill, but are below average. F-players (grey) are the failures, and wouldn't bring much good to the company.
On the left side of the building you see new hires joining the company. The colors of these represent the level you've selected to hire, from the controls. The controls are available in the top right side of your view port. Click it to expand it, or alternatively use the H key to hide/unhide it.
Within the main building you see current employees walking around as they do their job. Again, the colors of these represent the distribution of skill level within the company.
Then on the right side of the building you have previous employees leaving the building. These have either been fired or have quit by themselves. Employees of all levels will with some probability choose to quit in any case, and it's assumed that the better an employee is the more external opportunity he/she has. Therefore, good employees are more likely to quit that less good employees.
To the right side of the building is a pie chart. This shows the current skill level share of the workers working for the company at the current point in time. Below the building and pie chart is a stacked line chart showing the skill level distribution over time.
Now to the fun part: changing parameters.
If you open the controls and pick example 1, you would over time start seeing a distribution somewhat similar to the example to the left. Here we're living in a very simple world: We know who are A- and B-level workers, hire only them, and fire any C-, D-, and F-level workers that happen to already be in the company.
There is no interaction between employee levels, so for example an A-level worker stays an A-level forever. This lack of interaction also implies that A-level workers are equally happy working with any other A-, B-, C-, D-, or F-level employee.
What we see when this example is stabilizing is that the company is dominated by B-level employees. This is purely because A-level workers have a higher tendency to quit than B-level workers. As these are replaced we have an equal probability of replacing him or her with either an A- or B-level person.
This is however maybe a bit too simplistic. It doesn't seem likely that a top level employee would enjoy being managed by a less skilled manager, or constantly fix issues introduced by less skilled peers.
It also doesn't seem right that people stay at the same lever forever. As technologies, methodologies, and best practice changes over time, people will need to update themselves in order to maintain their knowledge and skill.
In example 2 the following changed:
We stopped firing C-level employees as it didn't make sense in many cases, it was costly, and there were legal issues surrounding it as well.
We assume that 1% of employees will go down one level per iteration, due to lack of training.
We assume a 10% group dynamics boost.
Group dynamics boost is what controls the interaction between levels and the likelihood that it will increase or decrease the probability of someone quitting. For example: A B-level employees have a 70% chance of staying, but with a boost factor of 10% this will increase to a 77% chance of staying if the B-level employee is working with a majority of A- and B-level people. If however there were more C-, D-, and F-level employees than A- and B-level employees, this boost factor would instead increase the likelihood of leaving from 30% to 33%.
The group dynamics especially creates interesting non-liner relationships which might drastically change what distribution the skill level stabilizes at. I do very much believe that people get influenced a lot by whom they work with, and that this affects how likely they are to either stay or leave a company.
This is really bad news. As we all know "A-players hire A-players and B-players hire C-players", and we now have a company dominated by B-players.
One way to solve this is to apply some solid internal training. If we do this right, as shown in example 3, we assume that 3% gain one level per iteration (level up).
This in itself is enough to create a company that is dominated by A-level employees.
Another thing is to define what we call high skill employees, and specifically target these if they decide to quit. Basically what this option will do is to reiterate their decision. They will enter this second decision using their usual transition probabilities, giving the company another chance of changing a high skilled employees decision to quit, potentially keeping the high skilled employee.
Example 3 also utilized this high skill option to try to retain A- and B-level employees.
I'll let that be last example and leave you to experiment with the parameters as you see fit.
This simulation experiment is within the definition of what we call a Monte Carlo simulation. We do random sampling, put those samples through a set of criteria and operations, and look at the resulting output. Often Monte Carlo simulations just present the final output after a set number of iterations, with a fixed set of parameters. Here however you're able to see the result as it evolves over time, in addition to dynamically change the parameters.
Initially this was all developed in Clojure, but when I thought about presenting this in a blog post it became obvious that it would be of more value to be able to easily interact with the code. It was therefore modified to be developed in ClojureScript instead, so that it would run in your browser. In addition to ClojureScript I'm making heavy use of the async library, wiring various components of the code through channels. This is also how it communicates with the web worker, allowing the core parts of the simulation to run in a separate thread.