Categories of leadership on technical teams

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:^{✻✻ These categories are a good starting point for figuring out how to divide team leadership work, but of course reality is fuzzier and messier, and responsibility won't break down exactly along these axes. Plus, being responsible for an area doesn’t mean being the only person that contributes; all of these benefit a lot from input from other people!}

Categories

Overall direction

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:

• Setting the team’s mission, vision, or charter
• Choosing the team’s goals, plans and roadmap
• Prioritizing the various different projects the team could take on
• Communicating the above, both to team members and to people outside

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

People management means being responsible for the success of the people on the team, most commonly including things like:

• Coaching people to improve and grow in their careers
• Designing and overseeing hiring processes for their team
• Setting and communicating performance expectations and evaluating against them

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

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:

• Setting and running the team’s “operating cadence,” i.e. the set of recurring meeting/rituals that help get work done (standups, planning/prioritization meetings, retrospectives, etc.)
• Figuring out how to split up work across the team, delegating it to whoever will do it, and monitoring progress to make sure it stays unblocked
• Keeping the team oriented by making work visible, through e.g. keeping Slack channels organized, maintaining a task tracker, and so on
• Being the point of contact between the team and the rest of the company—conveying important updates back and forth, etc.

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

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:

• Setting technical direction (e.g. the research agenda for a topic, or the architecture of a system)
• Reviewing execution against that direction (reviewing experimental designs and results, technical design docs, code review, etc.)
• Other technical mentorship of ICs on the team, e.g. 1:1s, pairing, etc.
• Often some amount of individual execution, though this can vary depending on how busy the technical lead is.

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.^{†† It’s worth noting though that technical leadership is not the only way to achieve high impact as an individual contributor! For a software-engineering-specific unpacking of other archetypes, which translates partly but not entirely to other technical domains, see Will Larson’s post on Staff engineer archetypes.} 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.

Example divisions of responsibility

Here are a few different real-world examples of how these responsibilities can be divided up.^{‡‡ These are extremely non-exhaustive, and are still an oversimplified schematic—on any given team, the exact division will depend on the skillsets of the leaders involved, and there will be lots of fuzziness and overlap!}

The “tech lead manager”

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:

• the team is small or low-pressure so that they have more time to focus on their growth areas
• the TLM has a highly engaged manager-of-managers who can support them where they need help
• the team’s domain is simple enough, or the ICs senior enough, that the need for technical oversight is limited
• the TLM has strong prior experience in both tech leadership and people management
• the TLM is up for working a large number of hours (this is, of course, descriptive and not normative)

Engineering manager / tech lead

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.).

Product manager / tech lead

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:

• Wave was relatively technically simple, but complex from an operational and product perspective, so for the person accountable for overall direction, technical skill was relatively less important and operational/product skill relatively more so.
• We hired very strong people into the PM role, mostly by transferring the strongest people internally from other teams.
• Each team’s PM and TL had a very strong working relationship, such that they were able to communicate effectively about things like tradeoffs between velocity and tech quality, and didn’t end up resolving those via e.g. PM fiat.

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.

People manager / research lead

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.