Developing talent is harder than finding talent.

In my last post I discussed some of my recent experiences hiring software engineers and the lessons I've learned. In this post, I want to proceed to the next step after a hire is made–the development of that talent.

My father is a successful automative engineer. With over twenty patents, including inventing four wheel shift on the fly, he spent years developing teams of talent. He's reminded me on multiple occasions that developing talent is harder, and more costly, than finding talent.

It took me a little while to understand what that meant. Impulsively it's easy to think that if you hire knowledgable engineers that you don't have to develop them. They already have the skills needed, that was decided during the interview process. But I wasn’t considering all the angles. Engineers don’t just write code. They don’t just sit at a keyboard and type. They solve problems, typically as a team inside a larger organization.

Developing talent typically involves educating an engineer on a domain or at the very least sharing institutional knowledge. My father developed drivetrains later in his career. Drivetrains can be wildly different. The drivetrain he developed for the Dodge Viper is very different than the drivetrain he developed for a Land Rover vehicle. They both involved the same parts, like axles, but they are very different in their function. Same goes for software. Just because it is a Rails app doesn’t mean there aren’t sharp edges a new talent needs to be aware of. Maybe due to PCI compliance a certain popular technique can’t be used. Or maybe a non-typical pattern around indexing documents in Elasticsearch has been established. New talents need to be made aware and trained on the team’s solution. This can be a frustrating process for new hires. As a Director, or senior engineer on the team, this training and handling of the situation is a part of developing talent. Getting the new talent into a place of shared understanding is important for the team to function at a high level.

Of course, developing software isn’t just writing code or understanding where some functionality lies in a codebase. As engineers, we have a role on a team. That role defines a lot of our responsibilities. New hires require some time and help in understanding their role and responsibilities. Getting to the point where all team members understand their role is key in developing talent.

It’s understandable that more experienced engineers can identify their role more quickly than those with less experience. But even experienced engineers need some time to develop. Understanding process and when to take the ball and run with it are all things that a Director can help talent of any experience grasp.

Maybe the point my father is making is that it takes discipline and patience to develop talent into more than just a team member practicing the exact function you hired them for. Maybe developing talent is more about how they can practice their craft and be an active member of the team and organization.

As a Director, I'm constantly evaluating whether we are progressing and operating efficiently as a team inside a greater organization. Developing talent needs that same kind of evaluation. The parameters obviously change. But evaluating progression and efficient operation can be applied to an individual as well.

Many times we can focus reviews on a talent accomplishing tasks or showing increased learning in their craft. It's my intention to broaden that focus to include things like being a team member and understanding greater roles. That is how I can help measure my role in developing talent.

In my next post, I'll discuss team roles and what it means to be a solid member of a team.