A System to Improve An Underperforming Millennial Employee

One of the largest characterizations associated with the Millennial stereotype is laziness. Whether or not this is true, there are valid cases where younger employees fall behind in performance. In those particular cases, how do you address their lacking performance and create a system to improve their workplace contribution? Improving employee performance is a multi-set system that is taught in both corporations and university MBA programs which can be applied to all ages, and works especially well for younger employees who are just starting their careers.

In these steps, I will use an example of a coder who is underperforming at their position so you can see how these steps are applied in a practical way. If you are not from the tech space, this system can still apply, however, the actions themselves will differ based on the role.

1.   Overcoming Institutional Blindness -> Setting Clear Expectations

The first place managers need to look at improving employee performance is at ‘institutional blindness’; a paradigm that inhibits managers from having an objective view of a role. For instance, when you begin working at a new company and are listening in on your first meeting, sometimes there were so many new acronyms that you literally have  to write them all down and ask a coworker what they meant. Your coworkers were probably unaware of all of the acronyms they were using requiring you to uncover this knowledge, hence a sense of blindness. Another example when starting a new job is being able to see different ways on how a company can be run more effectively, but the current staff seems completely blind to it. Both instances are examples of institutional blindness. The language, process, or knowledge that is formed in a role, but the ones who participate in that role for a lengthy period of time become unaware of them, leading to a particular blindness.

As a manager, the challenge of overcoming institutional blindness involves making implicit knowledge explicit. Often, young employees have a lot of tactical knowledge, but lack practical experience to apply that knowledge to. Your job is to bridge this gap.

In this step, you will need to identify the expectations that are implicit about a role and make those explicit. This will consist of writing down all of your expectations as a manager regarding your employee performance in their role. When you do so, you will find it much easier to see where the employee performance break down is occurring.

Example Expectations:

• Tests should always be written for new code.
• When code is pushed to production there should not be any or very few bugs in the code.
• Code reviews should have a limited number of reviewing rounds.

Now that we have a few expectations written down, it is now appropriate to move to the next step where we will break those expectations into measurable ones so improvement will become a black and white rather than qualitative.

2.   Measure the Expectations

Ultimately, you want everything that you expect of an employee measurable. A few examples:

• Coder: how many story points are finished during a sprint.
• Content writer: how many blogs they are posting each week.
• Designer: how many projects they get done in the week.

Given enough thought, any position can have activities broken down into measurable steps. The common industry term for converting steps and expectations into measurable ones is called ‘Key Performance Indicators’. In other words, what key thinks indicates that an employee is doing their work. Usually KPI is referred to one tasks not others, in this post, I will use it as term that compasses all measurable expectations.

Let’s take the expectations in the previous example and measurable expectations.

• Tests are written for the new code

So how do you break this down into something that is measurable? Simply telling a coder to have tests written for their code then later finding out that they wrote tests but they don’t test the ‘right’ things is not a long term solution. The coder did exactly what was required of them but it did not meet the manager’s expectation. Instead of blaming it on the coder, the root problem comes from not making statements explicitly clear. There needs to be a way to measure whether or not the coder has done a good enough job with writing tests where debate is left out of the question.

For this situation, code coverage and adding user scenarios (how a user can interact with the code) are effective ways to make the expectations measurable. For code coverage, the tests should cover a certain percentage of the lines of code, while the user scenarios can be decided upon before the code is written. Now, when the code is finished, a manager can simply compare the new code to the set expectations that are now measurable and can confidently say whether or not their direct report has adequately met their standards.

• When code is pushed to production there are not bugs in the code.

So how do you break this down into something measurable? How do you really know that there are no ‘bugs’ in the code? This one gets a bit tricky because there are various people involved with the deployment process. In engineering teams, there is the person who writes the code, the coders who reviewed the code to ensure its written the right way, and the Quality Assurance team who verifies that the code works correctly avoiding any possible bugs. It is a group effort. In this case, a manager cannot guarantee that there won’t be bugs on production so they should set a quantitative barrier such as 100 lines of code to have under 3 bugs.

There are many ways to handle this issue, and while the solution above may seem like a broad brush stroke for a complex situation, the point here is to quantify this example so that the manager can easily see if the direct is meeting his or her expectations.

• Limiting the rounds of code review.

Again what will be the best way to break this down to something measurable? On coding teams, too many rounds of code review can distract other programmers from writing their own code. In this case, the number of code reviews can be quantified by number of lines, and complexity (which can be estimated by the rest of the engineering team) and equate that to the number of rounds acceptable.

3.   Building a Checklist

With all of these expectations quantified, you will now need to create a checklist for the employee to follow so that they are able to meet the expectations. For the expectations above here is a sample checklist for writing a new piece of code.

Employee receives a new ticket requiring a new code feature and is now required to fill out the following checklist:

• Write down all user scenarios.
• Write out the individual steps to build the new feature.
• Create tests that cover all of the user scenarios (since the code is not written yet, all tests will be initially failing)
• Build out each individual part of the code and ensure that all test pass.
• Review code and look for areas where it could be cleaned up.
• Go to step 1, if all user scenarios are covered then push the ticket up from code review.

Now that all of your expectations have been written down into a checklist format, an unexpected benefit will arise- you will no longer have to micro manager. Reason being, you will be able to let go and see whether or not your direct will sink or swim because you know exactly what is required of them. Simply give them the assignment, and compare their results by looking through the checklist. If you had not go through making your expectations explicit, you will find it extremely difficult to evaluate whether or not your employee has done a job successfully. However, if they are not successful in their performance improvement after completing the checklist, it is important to evaluate if the checklist should be improved, hence going back to steps 2 if there are any expectations you have not made explicit yet.

4.   Setting a Deadline

With the new checklist system in place, the next step setting a simple deadline of when you and your direct will meet next to evaluate their performance. This could be a several days, week or a month. Regardless of what it is, it is paramount to hold your integrity to this deadline. If you don’t, your direct report won’t take you seriously.

5.   Reinforcing Boundaries

After you meet with your direct report at the specified deadline, evaluate the results against the checklist and see if all was met. If the checklist was not checked off, your decision is clear on what you have to do. If the checklist was checked off and the performance is still lacking, then you will need to look closer at the processes and start at Step 1.

One of the most difficult activities to take part in as a manager is what to do when an employee is falling behind in performance. Almost no one enjoys firing an employee but now if you are faced with that situation, you will have practical steps to take to ensure that it is a good decision. And better yet, you will be able to give that Millennial or underperforming employee a fighting chance by creating a system where they can thrive.