Managing High Technical Talent in Machine Learning and Engineering

One of the things that makes leading ML and general engineering talent fulfilling and fun for me is the incredibly smart and talented teams and ICs (Individual Contributors) I get to work with. Throughout my career, both in AI/ML services and in data-driven product companies, I’ve looked for and been lucky to find many such high-talent teams—otherwise, I wouldn’t have enjoyed my career and probably wouldn’t even be here writing this. While these high-talent teams have been made up of all kinds of interesting and different individuals, they do all tend to 1) have certain traits that make them exceptional at what they do, but also 2) require a special type of management or leadership.

This kind of talent wants to do great work and is technically capable. They don’t care about titles, they see through inefficiency immediately, and they expect managers to operate at a high level. If you want to run a high-performing team, you need to recognize this and manage accordingly. I’ve worked with dozens of technical teams and managers throughout my career and have seen the difference between great and poor leadership. Two aspects that stand out as frequently overlooked or undervalued by poor leaders: leading by example and giving people protection and space to “let them cook”.

Leading by Example

Highly talented technical people respect competence. If you’re leading an ML or engineering team and are always just asking for things and never getting into the doing, that’s a quick path to having the team lose trust or confidence in you. Over time, they will start ignoring you (by necessity), and the morale and output of the team will suffer, eventually leading your high-potential team to mediocrity. Of course, one of the main responsibilities of leaders is to keep the bigger picture in mind and not always “look down the sights,” but there are always opportunities to contribute hands-on, and in my experience, you need to for both trust and understanding.

Unfortunately, I’ve seen too many managers believe they can delegate everything and focus solely on “strategy.” That doesn’t work with high-talent technical teams. If your team doesn’t believe you understand their work or the challenges they face (and you won’t if you strictly limit yourself to “managing”), they won’t take your guidance seriously—at least not for long. Stepping in when needed—whether reviewing code, helping debug an issue, doing legwork to clarify a data field, refining documentation, or handling a tough stakeholder negotiation—sets the standard and earns respect.

You don’t have to and obviously shouldn’t do the team’s work, but you need to demonstrate that you understand what good work looks like and be able and willing to contribute hands-on when needed. Strong talent knows you have other responsibilities, but even the smallest efforts to take on an IC role when the team is stretched or needs it will be seen, appreciated, and repaid. They need to trust that you understand their challenges, and conversely, you need to trust them—which you can’t do if you don’t have at least a baseline understanding of what it takes to do their work. This brings me to the flip side of trust and the next point:

“Let Them Cook”

Deep work is essential in ML and engineering, and strong talent will not just need and crave this time but also be highly sensitive to infractions upon it. Leaders who constantly interrupt this time not only destroy a team’s ability to get their most valuable work done but also chip away at their morale. In my experience, the worst offenders are managers who don’t understand what goes into the work or how answers are derived. This lack of understanding is often paired with a lack of confidence that manifests as frequent requests for updates, premature demands for results, and excessive processes imposed to maintain a sense of control. “Letting them cook” comes down to two key principles: trusting them and protecting them from chaos.

Trust your ICs.

Leading by example helps build trust, and as a leader, you should also trust your team’s IC abilities. If you don’t, either you or they are not in the right place. Beyond that, it’s your job to set goals, align on direction, and then let them execute. High-talent individuals know when to reach out and when they need time to figure things out. A good check-in cadence is perhaps a weekly 1-on-1—sometimes even that is too frequent.

I like to give my team a simple rule of thumb to ensure we’re aligned: “If you’re stuck for more than two hours without making progress, or if you need clarification on goals, reach out to me. Otherwise, I’ll assume you’re making progress and won’t interrupt you until our weekly 1-on-1.” Along the line of trust, listen to what they’re telling you. They are the ones in the data every day, they understand the intricate challenges and difficulties around the data they have to deal with. Too often I’ve seen managers listen to ICs raise issues around data or integrations and not take them as seriously as they should, sometimes even dismissing the issue outright because it’s inconvenient for their timelines and business goals. This not only erodes trust and morale but creates a snowball of tech debt that will come back around to kill productivity and velocity in the long term.

Protect them from chaos.

High-talent teams attract organizational chaos. Leadership will always look to them to fix urgent issues or take on sudden reprioritizations. Stakeholders and other teams will seek quick answers on pressing concerns because they know your team can help. A manager’s job is NOT to just pass along requests and delegate tasks—it’s to filter the noise and keep the team focused.

A good leader knows when to hold requests back instead of immediately passing them on. They negotiate realistic expectations, intercept distractions before they reach the team, and ensure the team has the space to do their best work. And, coming back to leading by example, a strong leader takes on some of the unavoidable requests themselves to reduce the burden on their team. Great leaders absorb chaos instead of distributing it.

A big point to also mention here is context switching. Yes, business priorities may change unexpectedly, and being agile as a team is crucial to maintaining high velocity and working on what provides the most value, but not every reprioritization needs to be passed down immediately. If an IC is two weeks out from finishing a model they’ve been working on for six weeks, it may very well be worth their sanity and sense of accomplishment to give them that time and delay the start on new priorities. More often than not in my experiences, that model they are working on comes back around to being useful in some unexpected but valuable way in the future. It’s your job as a manager to find the right balance and be sensitive to the fact that closing out a project properly will make the ramp-up and transition to the new priority that much faster as ICs can approach it with a clear mind and motivation rather than with a sense of incompleteness and uncertainty.

Final Thoughts

Just like any strong relationship, running a high-performing technical team has to be built on trust. Without it, even the most talented teams will struggle to stay engaged and deliver their best work. Throughout my career, I’ve seen trust break down in two critical ways: managers who fail to lead by example and those who fail to give their teams the space to work. If you want to build and sustain a high-performing technical team, lead by example, trust your team, and let them cook.