Discovering Gold On a Reclamation Project

My former employer often said during my career that people were our greatest asset. I was able to discover gold on a reclamation project for a poorly performing employee with days remaining before being terminated.

 A number of years ago, I took over an extraordinarily talented, small development group responsible for providing critical software on a telecom company’s self-healing network initiative. The team was only sixteen developers. The formal System Test and Digital Services Lab testing was done by another group within my organization.

I inherited one employee who was unfocused, could not stay on task, and could not seem to be able to think through the necessary steps to solve a problem. My problem was that this employee – Dimitri (not real name) ---- was a system analyst. I found myself managing around him. I had to give him extra time to develop specifications to hand off to a developer. His specs required numerous peer reviews, but he never could seem to get them to a level that someone else could begin developing. As a result, I could only give Dimitri’s specs to my most senior, skilled developers because they were going to have to re-write them on an already shortened schedule due to Dimitri’s delays. My senior developers were incensed to get a spec from Dimitri because of all the extra work to re-create specs and then develop the functionality on a shortened schedule.

After several months of giving Dimitri special assignments that I thought he could handle or by only assigning him the most basic spec functions, I was weary of managing around him.

I have always been a good salesperson, so I talked my boss into agreeing to cover Dimitri’s salary for the remainder of the year if I could get one of his former managers to take him back. The net / net was that they gained an analyst headcount at no cost for the remainder of the year. In an IT resource constrained environment, that was an incredible deal. Dimitri had moved from NJ to GA five years earlier and had changed organizations every year. I suddenly understood why. Not surprisingly, none of his former managers were willing to take him back and they all confirmed that my experience was the same as theirs had been while Dimitri was on their teams. They just never dealt with the problem.

I put Dimitri on a performance improvement plan with the understanding that if he did not improve, then he would be out of a job at the end of the performance evaluation period. I told my boss that I was certain that Dimitri would not be able to complete the performance improvement plan successfully unless something radically changed. I knew that he was the single breadwinner in his large family, so terminating him was not something that I took lightly.

The conversation with my boss occurred coincidently when our development location was hiring recent college graduates into an initial Analyst Training program. It was a 13-week course for recent college graduates who were conditionally hired and had to pass the class to retain their positions.

It was a perfect fit for Dimitri. I was not sure whether his inability to write coherent, logical specifications was due to either 1) an interpersonal issue with me, 2) poor training initially 3) he had forgotten his earlier training, or 4) he lacked the skills to be a spec writing Analyst.

The class evaluated the trainees on their ability to 1) think through a problem logically, 2) identify and articulate the steps necessary to solve the problem, and 3) analyze data necessary to validate that the solution worked as required. The class had various modules to help the trainee develop the skills to be an analyst and culminated in a timed case problem at the end where they had to take some raw business requirements, create a specification that addressed the problem with a solution, and verify that the solution worked by producing the appropriate outcome.

The trainer of the class and I had a conversation about Dimitri’s situation and agreed that he would be treated like the other trainees. Similarly, he needed to pass the class to keep his job. Dimitri and I had a corresponding conversation regarding his need to pass this class to retain a job.

I kept checking with the trainer over the 13-week period, but the news was not good. At the end of the 13 weeks, Dimitri did not successfully pass the class. He could not think through the problem logically nor was he able to identify and articulate the steps necessary to solve the problem. However, he was able to analyze data to validate whether his solution worked or did not work. His solution did not work, but he correctly validated the data indicating that his solution did not work.

I was not keen on terminating him due to his personal reasons, however I had developed a new need on my team that his data analytics skills were worth enough of a match to try.

I was starting a functional testing team to do functional validation of all the code compiled each night from my various developers. I needed better functional validation of the final compiled code before the formal handoff to the system testing team and Digital Services Labs testing team. I assigned Dimitri the task of creating automated testing scripts, executing those scripts daily against all the newly compiled code from overnight, and validating the automated script outputs to see what performed correctly and what required developer remediation.

Dimitri excelled at that task. After several months we moved him over to the System Testing team to perform the same function.

Funny thing happened. Dimitri went from being the worst performing member in the organization (not just my team) to the best performing tester in the organization. In those days, if your production code broke in the middle of the night, you got the callout to remediate it --- usually in real time if it was a Sev 1 or 2 production issue. As Dimitri became the most proficient tester in the organization, my developers began to request that he be the System Tester on their code. They recognized that if Dimitri System Tested their code to his standards, then they would only rarely receive callouts for system breakages.

Several years later, Dimitri became the System Test Manager and instantiated his discipline into the remainder of the System Testers. He remained one of the top performers in the organization.

Eventually, he left my employer and moved to another company as a System Test Manager. He was successful there too.

I always considered the Dimitri story to be my most successful story as a manager. We usually give up on people because of poor performance. Often people are in roles that poorly utilize their skills to the best advantage.

Dimitri was a diamond in the rough. No one had ever spent the time to adequately match his skill set to the functions needing to be performed. Being told continually that you are failing becomes a self-fulfilling prophecy. His re-training helped to give him confidence that he could perform a role --- though different from the role that the training provided. When he got into a role that matched his skills, he excelled. He became a top performer and subsequently a leader on the team.

Discovering gold on a reclamation project required taking risks and not giving up on a person who was struggling. However, in the end it was gratifying to see a person succeed in a role that matched their skills and subsequently transition from the worst performer in the wrong job to a top performer / manager in a job that matched his skills.

There is an old proverb that says give a man a fish and he will eat for a day, teach him to fish and he will eat for a lifetime. Sometimes you just have to change the fishing lures / bait to catch the fish that are biting.