Developing Engineers Who Direct Themselves

Every Role Is Changing at Once

Most engineering teams contain multiple disciplines. A typical ML product team might include machine learning engineers, software engineers, data scientists, annotation specialists, tooling engineers, and domain experts. Each discipline has its own vocabulary, its own mental models, and its own definition of “good work.” In stable times, a manager can coordinate across these specialties by assigning work, tracking execution, and shipping on schedule. The disciplines stay in their lanes and the system works.

We are not in stable times. AI is disrupting every technical discipline simultaneously, but differently. ML engineers face the question of whether the models they build will be replaced or augmented by foundation models. Software engineers are watching copilot tools reshape how code is written. Domain experts who built rule-based systems are seeing generative approaches challenge what they spent years refining. Data scientists are watching their analysis workflows get automated. Annotation specialists are confronting a future where labeling shifts from human judgment to synthetic data. Tooling engineers are being asked to support fundamentally different architectures than the ones they built.

When one discipline is disrupted, you can retrain or reassign. When every discipline is disrupted simultaneously, the traditional management playbook breaks down. The tasks you assigned last quarter may be wrong by the time your team finishes them. The tools you built may be obsolete. The role someone was hired into may not exist in 2 years. In this environment, the most important thing a manager can do is develop each person’s capacity to think strategically about their own work: to diagnose where the real leverage is, to identify which work matters and which work is about to become irrelevant, and to direct their own effort toward the highest-impact contribution they can make.

Knowing Your People Across Disciplines

I hold weekly 1:1 meetings with every person on my team, not just my direct reports. The meetings are not status updates. I already know what everyone is working on. The purpose is to understand each person: what motivates them, how they think about their contribution, where their thinking is expanding, and where it has stalled. The goal is to see each person clearly enough to know what they need to grow.

When your team spans 6 specialties, you cannot rely on shared technical context to build that understanding. An ML engineer and an annotation operations specialist see the system through fundamentally different lenses. The ML engineer thinks in terms of model architectures, loss functions, and evaluation metrics. The annotation specialist thinks in terms of labeling guidelines, inter-annotator agreement, and data quality. Both are looking at the same system. Neither sees the whole picture by default. The manager’s job is to understand both lenses well enough to help each person see beyond their own.

This only works if the manager has genuine technical credibility across the disciplines. If I lacked the depth to engage with an ML engineer’s architectural decisions or a domain expert’s design choices, the conversation would stay at the surface: timelines, dependencies, blockers. With real expertise, the conversation goes deeper: is this the right problem to solve? Is there a simpler approach you haven’t considered? How does this connect to what the adjacent team is doing? I believe in a principle of experts leading experts at every level of the organization. The coaching has substance, not just encouragement, because the person giving it can see the technical frontier. You can expand someone’s vision of what’s achievable only if you can see that frontier yourself.

Shared Language Through Books

A diverse team with 6 disciplines has a fragmentation problem. Each specialty has its own vocabulary, its own mental models, its own definition of “good work.” Left alone, each discipline optimizes locally: the ML team builds the best model, the annotation team labels the most data, the tooling team builds the most robust infrastructure. Local optimization is the enemy of system-level performance. The annotation team’s labeling priorities should be driven by the model’s failure modes, not by what’s easiest to label. The tooling team’s infrastructure should serve the workflows that matter most, not the ones that are most elegant to build. These connections only happen when people can reason about the system as a whole, not just their piece of it.

We run regular book clubs, but not the kind most engineering teams are familiar with. Technical book clubs and journal clubs are common in the industry: a team reads a paper on transformer architectures or discusses a new framework. Those have value, but they focus on what to build, not on the nature of work itself or how to do good work in conditions of uncertainty. The books we read together are about understanding systems, making strategic choices, and navigating disruption, skills that no technical paper teaches. Two recent examples illustrate the approach. The first was The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford. It tells the story of an IT organization drowning in unplanned work, invisible dependencies, and single points of failure. The concept that resonated most was “Brent,” the one expert everyone depends on and who becomes the bottleneck for everything. Every team has a Brent. Identifying who your Brent is, and understanding why that concentration of knowledge is a systemic risk rather than a mark of individual excellence, changes how people think about their work. When a junior annotation operations specialist starts talking about “the Brent problem” on their subteam, they are diagnosing a systems-level issue, not just reporting a workload complaint. They have a lens for seeing the organization as a system of flows, not just a collection of tasks.

The second book was Good Strategy/Bad Strategy by Richard Rumelt. Rumelt’s core argument is that most organizations confuse strategy with aspiration. “We will be the best at X” is not a strategy. A strategy is a diagnosis of the challenge, a guiding policy for addressing it, and a set of coherent actions. We focused on how each person could develop a strategy for their own work: what is the central challenge in your domain right now, what is your guiding policy for addressing it, and what are the specific actions that follow? When an annotation lead can identify weak points in models across strategic product areas, design a data collection effort targeting those weaknesses, and feed the results back into model improvements, they are thinking strategically about their domain. They are not waiting for a manager to connect annotation to model quality. They see the full loop and they are driving it themselves.

The book clubs serve a second purpose beyond individual development: they create a common vocabulary that bridges the 6 disciplines. When the data scientist and the tooling engineer both understand flow, bottlenecks, and the theory of constraints from The Phoenix Project, they can diagnose cross-functional problems together without needing a manager to translate. When the language engineer and the annotation specialist both frame their challenges using Rumelt’s diagnosis/policy/action structure, they can align their efforts without needing someone above them to coordinate. The shared language makes the diverse team function as one system rather than 6 silos.

The Shift: From Execution to Self-Direction

The visible sign that the development is working is when subteams and individuals start identifying the right work to do on their own. A junior engineer who arrived thinking “my job is to close the tickets assigned to me” begins diagnosing systemic bottlenecks and proposing solutions that cross discipline boundaries. An annotation operations specialist starts building tooling to automate the repetitive parts of their workflow, not because a manager suggested it, but because they read The Phoenix Project and recognized that their manual process was the constraint. A language engineer starts learning ML, not because their role was redefined, but because they can see that the boundary between rule-based and statistical approaches is dissolving and they want to be on the right side of it.

This role expansion is one of the most important consequences of developing strategic thinkers. When every discipline is being disrupted, the boundaries between them dissolve. The annotation specialist who builds tooling is not crossing a boundary for fun. They are responding to a real change in where the leverage is in their domain. The language engineer learning ML is not diluting their expertise. They are following the work to where it matters. The manager’s job is to make that expansion safe and supported: to give people permission to grow into adjacent territory, to provide the frameworks that help them navigate unfamiliar ground, and to ensure that the team’s structure rewards breadth as well as depth.

The alternative is a team that fragments under disruption. Each discipline retreats into its specialty, defends its territory, and resists the changes that threaten its traditional role. The ML team insists that foundation models are not ready. The annotation team insists that human labeling remains essential. The language engineers insist that rules still outperform statistical methods for their use cases. Each of these claims may be partially true. None of them constitutes a strategy. A team of strategic thinkers can hold the partial truth while still adapting. A team of pure executors cannot.

The Result

The outcome of this approach is a team where subteams work independently to maximize their impact, surfacing new ideas that the manager did not originate and would not have thought to assign. The annotation operations group builds tooling that reduces labeling time by half. The language engineering group proposes an ML-augmented approach that their predecessors would have considered outside their scope. The data science team identifies a quality signal that the ML team had missed because they were looking at the wrong evaluation metric. Each of these contributions came from individuals who had developed the strategic capacity to see what mattered in their domain and act on it without waiting for direction.

For the individuals, the development path is clear: an engineer who can diagnose the central challenge in their domain, develop a coherent strategy to address it, and execute independently is an engineer on the path to technical leadership. The strategic capacity that makes the team perform also makes the person’s career advance. These are the same skill. Developing one develops the other.

The manager’s time investment, weekly meetings with every team member, regular book clubs, and continuous coaching across disciplines, pays for itself because the team scales beyond what any single manager could direct. No one person can identify the highest-leverage work across every discipline and every product area. You need people who can each identify it in their own domain. The only way to get there is to develop them. As AI continues to reshape every technical role, this is the management challenge of the next decade: not directing the work, but developing the people who will figure out what the work should be.