This is an adaptation of an internal doc I wrote for Anthropic.
Recently I’ve been having a lot of conversations about how to structure and staff teams. One framework I’ve referenced repeatedly is to break down team leadership into a few different categories of responsibility.
This is useful for a couple reasons. One is that it helps you get more concrete about what leading a team involves; for new managers, having an exhaustive list of job responsibilities is helpful to make sure you’re tracking all of them.
More importantly, though, we often want to somehow split these responsibilities between people. Team leadership covers a huge array of things—as you can see from how long this post is—and trying to find someone who can be great at all of them is often a unicorn hunt. Even if you do find someone good-enough at all of them, they usually spike in 1-2 areas, and it might be higher-leverage for them to fully focus on those.
Here’s a breakdown I use a lot:1
The most important responsibility a team’s leadership is to ensure that the team is headed in the right direction—that is, are they working towards the right high level goal and do they have an achievable plan to get there? Overall direction tends to get input from many people inside and outside a team, but who is most accountable for it can vary; see Example divisions of responsibility below.
Overall direction involves working on things like:
The most important skill for getting this right is having good predictive models (of both the team’s domain and the organization)—since prioritization is ultimately a question about “what will be the impact if we pursue this project.” Being great at communicating those predictive models, and the team’s priorities and goals, to other stakeholders is also important.
Good team direction mostly looks like the team producing a steady stream of big wins. Poor direction most commonly manifests as getting caught by surprise or falling behind—that is, mispredicting what work will be most important and doing too little of it, for example by starting too late, under-hiring, or not growing people into the right skillset or role. Other signs of poor direction include team members not understanding why they’re working on something; the team working on projects that deliver little value; friction with peer teams or arguments about scope; or important projects falling through the cracks between teams.
People management means being responsible for the success of the people on the team, most commonly including things like:
Day to day, the most important responsibility here is recurring 1:1s (the coaching kind, not the status update kind). Others include writing job descriptions, setting up interview loops, sourcing candidates, gathering feedback, writing performance reviews, helping people navigate org policies, giving career coaching, etc.
The most important skill for people management is understanding people—both in the traditional “high EQ” sense of being empathetic and good at seeing others’ perspectives, but also in the sense of knowing what contributes to high performance in a domain (e.g. what makes someone a great engineer or researcher). It’s also important to be good at having tricky conversations in a compassionate but firm way.
The main outcome of people management is whether people on the team are high-performing and happy. Teams with the best people management hire great people, give them fast feedback on anything that’s not working, course-correct them quickly, help them grow their impact over time, and generally help them have a great time at work. Bad people management looks like people chronically underperforming or having low morale.
A common question here is how technical a people manager needs to be. Opinions vary widely. The bar I typically suggest is that the people manager doesn’t need to have the most technical depth on the team, but they need enough depth that they can follow most discussions without slowing them down, understand who’s correct in most debates without needing to rely on trust, and generally stay oriented easily.
The people manager is responsible for making sure their reports get mentorship and feedback if needed, but they don’t need to be the primary person doing the mentorship or feedback themselves. Often, domain-specific mentorship comes from whoever is responsible for technical direction, but it can also come from anyone else senior on the team, or less commonly, somewhere else in the org.
Project management means making sure the team executes well: i.e., that everyone works efficiently towards the team’s top priorities while staying unblocked and situationally aware of what else is going on. In the short run, it’s the key determinant of a team’s productivity.
Day to day, project management looks like:
Project management isn’t just administrative; doing it well requires a significant amount of domain expertise (to follow project discussions, understand status updates, track dependencies, etc.). Beyond that, it’s helpful to be organized and detail-oriented, and to have good mental models of people (who will be good at what types of work? What kinds of coordination rituals are helpful for this team?).
Good project management is barely visible—it just feels like “things humming along.” It’s more visible when it’s going badly, which mostly manifests as inefficient work: people being blocked, context-switching frequently due to priority thrash, flailing around because they’re working on a project that’s a bad fit, doing their work wrong because they don’t understand the root goal, missing out on important information that was in the wrong Slack channel, and so on.
When teams get big, project management is one of the areas that’s easiest to delegate and split up. For example, when Anthropic’s inference team got up to 10+ people, we split it up into multiple “pods” focused on different areas, where each pod had a “pod lead” that was responsible for that pod’s project management.
Technical leadership means being responsible for the quality of a team’s technical work. In complex orgs integrating multiple technical skillsets, you can think of teams as often needing some amount of tech leadership in each one—for example, research teams at Anthropic need both research and engineering leadership, although the exact balance varies by team.
Specific work includes:
Because technical leadership benefits a lot from the detailed context and feedback loops of working on execution yourself, it’s fairly common for tech leads to be individual contributors.2 In practice, many teams have a wide enough surface area that they end up with multiple technical leads in different domains—split either “vertically” by project, “horizontally” by skillset, or some combination of the two.
Perhaps obviously, the most important skill for a tech lead is domain expertise. Technical communication is probably next most important, and what separates this archetype of senior IC from others.
When technical leadership isn’t going well, it most often manifests as accumulating debt or other friction that slows down execution: bogus research results, uninformative experiments, creaky systems, frequent outages, etc.
Here are a few different real-world examples of how these responsibilities can be divided up.3
When a new company introduces their first technical managers, they often do it by moving their strongest technical person (or people) into a management role and expecting them to fulfill all four responsibilities. Some people do just fine in such roles, but more commonly, the new manager isn’t great at one or more of the responsibilities—most often people management—and struggles to improve due to the number of other things they’re responsible for. (Further reading: Tech Lead Management roles are a trap)
Although TLM roles have some pitfalls, they’re not impossible. Here are a few protective factors that make them more likely to succeed:
This type of split is common in larger tech companies, with the EM responsible for overall direction, people and project management, and the TL responsible for technical leadership (and potentially also contributing to overall direction). “Tech lead” doesn’t have to be a formal title here, and sometimes a team will have multiple tech leads in different areas.
At Anthropic, a good example of this is our inference team, where the managers don’t set much technical direction themselves, and instead are focused on hiring, organizing, coaching, establishing priorities, and being glue with the team’s many many client teams. Since the domain is highly complex and the team is senior-heavy, tech leadership is provided by multiple different ICs for different parts of the service (model implementation, server architecture, request scheduling, capacity management, etc.).
This is an example of a less-common split. At Wave, we used a division similar to the EM/TL split described above, but the team managers (which we called Product Managers, although it was a somewhat atypical shape for a PM role) often came from non-technical backgrounds.
PMs were expected to act as the “mini CEO” of a product area (e.g. our bill payment product, our agent network, etc.) with fairly broad autonomy to work within that area. Because the “mini CEO” role involved a bunch of other competencies, we decided they didn’t also need to be as technical as a normal engineering manager might.
Although unusual, this worked well for a couple main reasons:
Notably, this broke the suggestion I mentioned above that people managers should be reasonably technical. This worked mostly because we were able to lean heavily on tech leads for the parts of people management that required technical context. Tech lead was a formal role, with secondary reporting into an engineering manager-of-managers; and while PMs were ultimately responsible for people management, the TL played a major role as well. Both of them would have 1:1s with each team member, and performance reviews would be co-written between the PM and the TL.
Anthropic has a few examples of splitting people management from research leadership; the longest-running one is on our Interpretability team, where Chris Olah owned overall direction and technical leadership, and Shan Carter owned people and project management. (This has changed a bit now that Interpretability has multiple sub-teams.)
In this split, unlike an EM<>TL split on an engineering team, it made more sense for the research lead to be accountable for overall direction because it depended very heavily on high-context intuitive judgment calls about which research direction to pursue (e.g. betting heavily on the superposition hypothesis, which led to several major results). Many (though not all!) engineering teams’ prioritization depends less on this kind of highly technical judgment call.
This is interesting as an example of a setup where the people manager wasn’t (primarily) responsible for overall direction. It’s somewhat analogous to the CTO / VP Engineering split in some tech companies, where the CTO is responsible for overall direction but most people-leadership responsibility lies with the VPE who reports to them.
Thanks to Milan Cvitkovic and many Anthropic coworkers for reading a draft of this post.