Mold the Role to the Person, not the Person to the Role

Ken Kao
4 min readApr 9, 2019

--

What I Learned from the Biggest Management Mistake of My Career (So Far)

Image by Natallia Rak via pexels

A few years ago, an engineer on my team, Todd¹, came to me about growing at the company. He wanted to be a tech lead and asked what he should work on. After I reflected on my responsibilities, I identified three key areas: (1) technical execution, (2) project management, and (3) client engagement. I explained to Todd that he was great at (1), decent at (2), and we could work together to improve on (3).

I started coaching Todd on team management and asked him to run more internal meetings and plan our technical roadmap. I brought him to client meetings and we would debrief afterwards, discussing how the meetings went and why we explained certain concepts in different ways. I also encouraged him to increase his participation in client meetings, as we were on a client-oriented project team and aligning closely with the client was crucial to our project’s success.

A few months later, my manager asked if I felt comfortable making Todd a tech lead. The company was undergoing rapid expansion, and there weren’t enough tech leads to allocate to all the inbound business interests. I was hesitant to make Todd a tech lead — although Todd was improving, there were still areas he needed to work on before he could independently lead a client project.

We ended up agreeing on a compromise. I was about to go on vacation soon, so Todd would take over as Interim Tech Lead while I was out. Since he had already been on this project for a while, the familiarity would make this a lower-risk proposition than asking him to lead a new project. I handed off my responsibilities over the next few weeks and left for vacation.

Right before my vacation, one of the features my team was working on for a client was authentication. Since the team completed the feature while I was out, Todd emailed the client users for the rollout. Unfortunately, he included all the users in the same email and attached a table with every user’s full name, username, and password.

Needless to say, the client was not thrilled with this lapse of security. The Business Lead, in particular, was furious. News spread, and I soon received some very angry emails from higher-ups, as well as calendar invites for 5-whys. Fortunately, we had a strong track record with the client and after a few calls and a lot of apologizing, were able to continue with the partnership.

In retrospect, my biggest mistake was trying to model the tech lead role after myself. The Business Lead and I complemented each other — he was very good at setting the vision and coming up with moonshot ideas, while I was good at balancing that with reality when discussing deliverables with clients. This partnership led to a successful project, but a tech lead with a different set of skills could be equally successful.

Despite Todd’s proficiency in other areas, he did not have the requisite mindset to handle client interactions yet. That said, it didn’t mean that he couldn’t be a tech lead. What I should have done instead was have Todd drive technical execution and internal project management and ask another team member to handle client communications. This would enable all parties to build on their strengths, which, according to research, is crucial to successful outcomes.

After the incident, Todd went back to being an individual contributor and is now enjoying success as a tech lead at a different company. All’s well that ends well, but as his manager, I failed him by not setting him up as a team lead in a way that better suited his strengths. It is a reminder that as managers, we can have a disproportionate amount of influence on our reports’ career trajectories.

Molding the role to the person impacts an entire organization’s success as well. Across the tech industry, executive roles and responsibilities are often defined using the skill set and experience of the executive as a guide. At Google, Eric Schmidt was brought on as CEO to run business and operations, while Larry Page concentrated on product development and Sergey Brin on moonshot projects. Facebook’s CEO Mark Zuckerberg focuses on product development while COO Sheryl Sandberg runs the business side of the company. In both cases, they molded the roles around the people, which allowed them to focus on what they each did best, resulting in multi-hundred-billion-dollar companies.

I have also seen the reverse play out, where management force-fits square pegs into round holes. In one instance, an engineer I knew requested a compensation adjustment for his growing contributions. Leadership’s response was to assign him a report and promote him to a manager role. He ended up spending his days in meetings he didn’t care about and having less time to code. Unsurprisingly, he left a few months afterward.

As companies scale in size, more processes inevitably get introduced. A common structure is to establish “ladders” and “promotion criteria” to ensure fair calibration across the board. While that may work generally, there will always be talented employees who do not fit perfectly into predefined categories but have the potential to make big contributions to the company. I encourage managers to assess their team members’ strengths and weaknesses and explore how to customize roles to maximize their team members’ impact. Best case scenario, you turbo-boost employees’ contributions to the company. Even in the worst case where the company doesn’t allow such flexibility and they end up leaving, they will still thank you for helping them learn to identify and hone their strengths.

[1] Names and identifying details have been changed to protect the privacy of certain individuals

For more musings on tech culture, organization building, and management, follow me on Twitter @kenk616.

--

--

Ken Kao
Ken Kao

Written by Ken Kao

Product-minded Engineering Leader. Organization & Cultural Builder. Traveler. Martial Artist (Muay Thai & Pekiti Tirsia Kali).

Responses (1)