The Bug-Solving, Underperforming Engineer

Problem

During the early 2000s, I was head of engineering at Movaris, a 50-person startup. I was asked, against my will, to hire an individual as a senior software engineer. However, organizationally-speaking he should have been hired as a software engineer, at best. I immediately noticed that he was not at the level expected of his position. His position and leadership were questioned by the engineering team and by not acting to remedy this situation, my credibility was being undermined.

Actions taken

"I realized that this engineer was great at fixing issues, and that I could create a win-win situation for him and the team."

I downgraded his role to software engineer and assigned him the role of "sustaining engineer", which allowed him to focus on things he was good at. When he began to excel at his new job it helped the team and the company. The team no longer had to respond to patch requests, as he handled them in his new role. The engineer has now been working there for almost 10 years and ended up staying at the company far longer than any of his contemporaries.

Lessons learned

"When an employee is not performing in a position, it doesn't necessarily mean that you should let him go."

I would recommend not just focusing on his weaknesses, but also thinking about their strengths, to figure out whether or not they could be useful to the team. In this particular case, redefining my engineer's position not only increased the individual's impact on the company, but also rehabilitated his reputation among his colleagues.