Background
I've wanted to write about this for the longest time and have finally decided to document this personal experience by reflecting on what transpired. I'll admit not having to commute into the office due to the ongoing social distance requirements of COVID-19 has also freed up some of my time. The events of this post transpire over a period of a few years. As always, no names shall be mentioned and everything will be presented in an objective manner with lessons learned.
At one of my jobs during my career, I was a Software Engineer on a very small team that started with 3 developers which expanded to include me as the 4th. I wouldn't say we were the best Software Engineers on earth who churned out god-like code and hit every project deadline. However, I will say that I felt like we were all competent, contributed in our unique ways, grew and evolved with the technology stack, got things done with a few snags here and there, learned from our mistakes, and generally got along by supporting and motivating each other when necessary.
Initial Success
After the team did well and delivered on products, we grew to take on more responsibility within the company. Other various non-Software teams eventually got merged into us in order to re-brand group into an end-to-end solutions team. The times were incredibly good with the annual compensation and bonuses for success trending upward as well. This is any VP’s dream as the success of business operations increasingly depended on the software solutions that their team was delivering.
However we now needed more technical personnel to help as the number and complexity of solutions had grown exponentially. The initial team members were each promoted up one level on the corporate ladder, our former team lead became the manager and the developers that started the group (which included myself) became Senior level. The technical structure was now the original VP, the Software Manager and the Senior level developers who were expected to be leads to new team members. Of course we wouldn’t take these mentorship relationships in a pigeonholed 1-to-1 fashion, we decided to work as a team to try and integrate everyone equally.
Troubles
Unfortunately, there was one new individual who needed extra help. This person who we shall reference as Joe needed a lot of attention. For every single line of code a question had to be asked. Every task was done in a copy and paste fashion from software help bulletins found based on the general topics entered into Google search. To say that there was a gap between the technical knowledge of Joe and the rest of the team is a massive understatement. It was very strange at first because Joe had some reputable certifications on his CV and had been working on some scripting portions for a business related system in another part of the company before the transfer into our group.
At first, all of us thought he needed time to adjust and pickup the Microsoft technology stack (MSSQL, IIS, C#, ASP.NET, Azure) that our group was using. There was plenty of time and effort budgeted and dedicated to his acclimation along with all the other new team members that were merged into the group. The learning curve may have been harsh for those who have never seen programming languages, but it was fair and they were allowed to make mistakes and grow. Some new team members hit the ground running while others learned how to run over the period of a few weeks.
After a few months to half a year, the gap in production was so wide from all of us when compared to Joe that it couldn’t be hidden anymore. One of the senior engineers needed to be at his desk at all times where code was dictated to him. When design or implementation questions were asked during these “pair programming” sessions, the only answer he would give is “Whatever you think is the best.” I offered extra help in the form of tutoring sessions after work hours to build a foundation of Software Development knowledge in areas such as Data Structures, Time Complexity, and Algorithms. When one of the senior engineers weren’t available to provide “hand holding”, his work simply did not get done. The tasks assigned to him kept being pushed into the next sprint until the stakeholder needed the feature delivered. They were then re-assigned to other team members with new tasks given to Joe.
Downfall
The surprising part in all this is that our VP and management was aware of this. The Senior Developers and our group’s manager brought this all up the chain multiple times. Absolutely nothing was done and there were no actions taken at all. It was getting so bad that the other Senior Developer who was already frustrated that she was receiving less compensation than Joe started looking for different opportunities and left. From my point of view, I was more discouraged by the fact that time and energy that I used to support Joe was ultimately wasted. I ended up looking for another opportunity as well at almost the same time the company had a bad year in terms of sales. I survived the company’s layoff phase but received an offer right afterwards so I ended up leaving as well.
Lessons Learned
After my exit, the VP did talk to me off the record sometime afterwards and state that the plan was to keep the obvious non-performer in order to save someone else during any reductions in force. I agree that this is an excellent business move as a hard decision does not have to be made when selecting which productive employee to layoff when the time came. However, I don’t think it is the best management move. It came at too great of a cost to team productivity and overall happiness. When a team moves at a certain speed and one person is dramatically lagging behind it (or even moving too fast) the dynamic is negatively affected. The business would have liked to keep the 3 original developers as they knew the systems the best, but only ended up keeping 1 because the other 2 left voluntarily. The rest of the new members that joined the team after expansion were also and laid off or left on their own shortly after except for 1 person.
I definitely think that I have failed in training Joe to be a Software Developer. I try to ask myself what I could have done differently. Maybe my teaching style was just not that effective. It’s also funny that my co-workers and everyone who knew first hand of this situation assure me that the failure was more on the student than the teacher in this case. However, I still felt disappointed that I did not get the job of on-boarding new team members done.
Another lesson that I take away from this experience is evaluating Software talent or any addition to a team now that I am in a lead position. The basic Computer Science principles need to be there of course, but the passion to learn, improve, and contribute to the team also matter alot. A person is given the opportunity to catch up, however there is a time limit and results of improvement have to be shown. Otherwise the entire team might get their creativity and resources drained trying to endlessly help this person.
