What I learned Trying to Upskill a Tech Support Person to Engineering

Tailoring an Onboarding Process for a Non-Engineer

"They had been writing code during their personal time but wanted to upskill themselves and make larger engineering contributions."

Previously in my career, I was the head of an engineering team in a hyper fast-growing startup. It had come to my attention that an individual within the tech support org was enthusiastic about engineering. They had been writing code during their personal time but wanted to upskill themselves and make larger engineering contributions.

I brought them onto my team and gave them some time to ramp up with a three-month onboarding plan. The first month was dedicated to learning the basics of my team's technical frameworks. The second focused on a deep dive into the code itself, since each codebase has unique identities. The third month concentrated on acknowledging and fixing any problems with code.

My three-month plan was thoughtfully created and ran past other members of my team. We had ensured that the process was thorough and did not overlook any areas necessary to become a serious engineer.

How the Onboarding Process was Unsuccessful

"Feature delivery was strictly based on writing new code, and the team member struggled in that department."

The new team member was really successful when it came to modifying existing code. They could engage with bug fixes relatively quickly, but when it came time for them to deliver their own features, we began to encounter challenges. Feature delivery was strictly based on writing new code, and the team member struggled in that department.

We were swamped with legacy bugs at the time and it was a short-term win to put this person on fixing these bugs and manning the slack channels. It was bad for the long term since it delayed getting the above-mentioned signal which resulted in going overboard the initial agreed-upon evaluation timeframe of 3 months.

For a while, this worked, but deadlines began approaching, and our team needed to zone in on feature delivery.

When I spoke to this individual that did not have an engineering background, I felt that visibility was lacking. Without my team's deep-rooted technical skills through education and experience, this individual could not speak on the same level as the rest of my team, decreasing collaboration and innovation. Through the lack of these interactions, I learned that there's merit in having the ‘engineering craft': the way engineers design their code, abstractions, and interfaces.

Eventually, after about five months, the time came to make a decision regarding the new team member. It came down to the fact that they were not able to meet the performance of the rest of the team, and if I let them stay, I would be lowering the standards for everyone. My decision was made with the entire team in mind, as the group works as a whole unit rather than singularly.

While it was a tough decision to make, the individual stayed with the company in their tech support role, creating a positive outcome.

Enforce Guidelines During Onboarding

• Be very stringent about milestones when onboarding new members. It would have been a win-win if we had made that decision in 3 months.
• I recommend that others assign a mentor to new teammates from the beginning. They should connect with the mentor about any challenges or problems faced. If milestones aren't completed, there should be clear communication regarding the next steps.