2026-11-08 08:00:00
In March 2025, I went on a Jhourney meditation retreat that was one of the most profound experiences of my life, and deeply reshaped how I related to myself.
If you had told my pre-retreat self that this was going to happen, I wouldn’t have believed you. I’d done some meditation before—including a 10-day vipassana retreat—and while it didn’t do nothing, I was underwhelmed. I felt pretty resistant to spending that much time staring at the inside of my head: it seemed really hard to actually trust anything I learned that way, because it was such a complicated system. And besides, my brain seemed to work fine the way it was.
I’d read some writing by serious meditators who seemed to be having a different experience, filled with insights and bliss, but it wasn’t one that I felt particularly drawn to. That much navel-gazing and wireheading felt self-indulgent, and anyway they seemed weird enough that whatever they were doing probably wouldn’t work for me.
Then, in a moment of life imitating Bay Area House Party, we got Jhourney, a meditation retreat startup promising to speedrun you to the bliss part (tagline at the time: “Life-changing meditative bliss used to take thousands of hours to learn. We teach it in a week.”) When I heard them strongly recommended not only by the serious meditators I’d been reading, but also by a couple more hard-nosed coworkers, I decided to see what the hype was about.
Jhourney teaches a style of meditation nominally focused on altered states called jhanas. Jhanas are blissful-feeling states that you can “relax into” if you release enough of what you might call tension or clenching or tanha, and then focus on an enjoyable open-hearted sensation like smiling, a joyful memory, or feeling care for a loved one. If done right, you can start a feedback loop of enjoying the enjoyment, and end up in a state of deeply absorbed euphoria.
I say Jhourney is nominally focused on that because the jhanas are actually kind of a Trojan horse for improving your life and relationships, which somehow doesn’t sell as well as wireheading. Jhourney’s unofficial motto is “come for the bliss, stay for the personal growth.” The growth happens because a lot of the tension you’re trying to release in jhana meditation is downstream of repressed or “stuck” feelings, either small ones (“I don’t want to be hearing that sound over there” leading to micro-clenching the head and neck) or big ones (“I can’t let myself feel this sadness or I’ll cry and that would be shameful” leading to tensing the various face and chest muscles that would otherwise be helping you cry). In order to get into jhana states, a lot of people (like me!) end up having to work on untangling knots of emotional clenching, and this usually leads to a lot of growth.
My first experience of my Jhourney retreat was showing up and being handed an 80-page handbook of meditation instructions.
This already blew my mind a little, because I had never read anything about spirituality or emotions that I considered good. The “best” stuff I’d read about the mind was vapid pop-psychology, padding out truisms with engaging fluff until the result somehow became a marketable book. The rest was indistinguishable from astrology—it was never clear enough that I could tell whether it applied to me, which meant it didn’t seem to make falsifiable predictions. As for spiritual writing, it mostly felt like word-association mumbo-jumbo, with authors throwing around words that had the right vibes but that I wasn’t sure they themselves even really understood. Heck, the previous meditation retreat I’d been on had included watching an hour-long recording of the now-dead founder talking about how he could sense quantum vibrations.
The Jhourney handbook didn’t have these problems, because it was written by software engineers. It was epistemically conservative and shockingly lucid, completely mumbo- and jumbo-free. To help with the inherently fuzzy language, they explained everything from multiple angles. They gave clear gears-level explanations of why they thought things worked the way they did. They even took a detour to explain their teaching philosophy so that students were oriented about why they were doing what they were doing. It was masterful pedagogy.
Between the written instructions and the teachings from live meditation sessions, pretty soon I could get to a point that felt like the “on-ramp” to a jhana. But every time I got there, I would get stressed and “grabby” about what to do next, and “fall off” the ramp.
By the time I got to day 4 of the retreat, I was feeling really frustrated about this, in a way that was starting to loop on itself. I was frustrated that I couldn’t reach jhana, and frustrated that the frustration was making things harder. I tried Jhourney’s recommended way of working with negative emotions, which was a self-compassion meditation. But no matter how much I tried, it didn’t really resonate; I couldn’t cultivate any emotional experience of self-compassion.
In fact, I realized I couldn’t remember ever having had a real emotional experience of receiving compassion, and that that was probably kind of fucked up.
A bunch of my friends were on the same retreat. Since I had no access to self-compassion, of course I used this realization to start worrying that they would judge me for having a hard time meditating because I was fucked up, adding even more layers to the feedback loop of doom.
Days 4–6 were pretty bad. Every day Jhourney gave us a survey of “how was your day on a scale of 1-10 with 5 as a normal day?” I rated day 6 a 1.5. (To their credit, Jhourney knew this meant I needed extra help and offered lots of 1:1 time with different facilitators, although none of it made that much difference.)
At this point, in one of my desperate attempts to think myself out of my feelings pickle, I started thinking a lot about the metaphor of the elephant and the rider. The idea is that people usually identify with everything that happens in their mind, but this is actually a confusion; it’s more accurate to think of “you,” the conscious part, as a small human rider perched atop a large lumbering elephant that often does its own thing. The only things that are actually in the rider’s action space are things like “say words to the elephant,” “visualize mental images to the elephant,” “direct attention to a particular aspect of experience,” etc. Everything else—including all emotions and many thoughts—is the elephant’s job.
In this frame, the fact that the self-compassion meditation wasn’t working for me wasn’t really “my” fault. Whether the emotional experience of self-compassion happened was up to the elephant, and the only thing “I” (the rider) could do was to keep gently saying the words or doing the technique or whatever, and wait for the elephant to steer, at its own pace.
Around that point I decided to give up on the Jhourney curriculum and just do whatever seemed like it would feel nice.1 I broke the rule of silence to ask for some reassurance from a close friend who was also on the retreat. When I got back to meditating, I made up a technique for myself where I imagined sending love and compassion to the elephant instead of to “myself.” This turned out to be a cheat code: I immediately felt an outpouring of warmth, and the reassuring things I was telling myself started to emotionally resonate.
I really wish I could describe better what happened after that, but unfortunately it was a while ago and involved a lot of subtle mental movements, plus it’s hard to track what’s happening while a chunk of your psyche is liquefying. I remember a sort of sense of “going inside” the feeling of compassion and love for the elephant, having it take up more and more of my attention, and feel more and more deep, rich and meaningful. Then some kind of rush of energy and a full-body frisson that I’ve learned often happens when my brain has rearranged itself.2
When I got up and walked outside, I gradually noticed that the world felt pretty different. I realized that I’d always carried a “refrigerator hum” of subtle body tension that was now gone. Walking around the retreat center looking at the views felt amazing, like I could have spent days just melting into the landscape. The Lipton peppermint tea at the hot drink station tasted unreasonably good. I would sometimes tear up with joy or gratitude for no reason. I felt much deeper care and connection with my friends.
Maybe that makes it sound a little gooey and impersonal, like I took a drug that replaced my normal self with a puddle of love or something. The actual experience was the opposite; somehow it felt like this was all happening because it was easier to be myself. The care and connection wasn’t coming from some foreign love puddle; it came out because a bunch of psychic gunk had sloughed off and made it easier for the real essence of Ben-ness to shine through.
And then I used my newfound mastery of emotions and self-compassion to live happily ever after flailed around trying to integrate everything back into normal life.
One of the big changes I noticed after the retreat was that my emotions got 2–3× more intense. I think this was net positive in the end, but it made coming back to work hard—I had a stressful role managing a large team, and I also needed to catch up from a week of being incommunicado, which was extra stressful. And it wasn’t exactly helpful that suddenly, if someone was annoying on Slack, it would sometimes make me want to shoot flames out my ears.
Over the next couple weeks, the intensity settled back down and the changes in my moment-to-moment experience went maybe 80% of the way back to normal (e.g., I stopped spontaneously tearing up in normal circumstances). Some of them stayed, though:
These were great changes, but even better, a bunch of mindset and relational shifts also stuck around.
Mindset-wise, I guess I’d just say I got feelings-pilled.
If you’d asked me what the deal with emotions was before the retreat, I probably would have said something like:
Positive emotions are nice, although you shouldn’t let them distract you too much from your long-term goals. Painful emotions are responses to stimuli that are part of our evolutionary inheritance, but are largely maladaptive today because we’re in an environment so different from where they arose. Assuming you have good enough self-control not to act out on them, their main effect is to make you dumber, which you should mitigate by not engaging with whatever makes you emotional until you’ve chilled out.
My new view is more like the following (this is still an oversimplified strawman and reality is a lot messier):
All emotions are important and beautiful components of unconscious/intuitive cognition.3 However, they sometimes create impulses to do things that aren’t actually good ideas. In the process of socializing ourselves not to follow those impulses, we’ve been trained to try to make the emotions themselves go away in painful ways, by repressing them or clenching up around them. Unintuitively, repression and clenching actually cause the emotions to “stick around” in some sort of partially metabolized state, which has negative side-effects, like anxiety, thought-looping, numbness, blind spots, impaired reasoning, bringing up secondary emotions as defenses, etc. A different way of working with these emotions, that’s better for you in the long term, is to figure out how to welcome and accept them. This eventually leads to them feeling less bad, and giving you more impulses that are good ideas and fewer bad ones. But it’s not as simple as “just stop repressing.” Welcoming emotions requires fully feeling them; if they’re strong, that can be too overwhelming to work unless you have a deep felt sense of safety. That safety can be provided in many different ways, e.g. a therapist, friends, some kinds of meditation, etc. If you don’t have access to enough safety, repressing or clenching temporarily might be your best option.
The main thing that changed my view here was spending days at the retreat paying close attention to my own emotional experience. For example, near the beginning of the retreat, one of the facilitators claimed that thought-looping was usually a sign of a stuck or repressed emotion. I was really skeptical, but then I had several very clear experiences of thought-looping around something, going off to a private place to cry about it, and immediately stopping the thought spiral and relating to it differently.4
Similarly, I’d ended a long-term relationship right before the retreat, which I’d felt a lot of internal conflict and self-doubt about. My therapist had often told me things like “if you felt enough of your feelings you’d feel clear about this decision,” which sounded crazy to me at the time (uh, it’s a really hard call and there are a lot of tradeoffs that I don’t know how to weigh!). But on the last day of the retreat I noticed that I felt much clearer that a lot of the things I didn’t like about that relationship were real and important, and felt much more confident in my choice to end it.
Of course, I’d already heard plenty of people say things like “you can’t make this kind of decision logically, you have to listen to your heart,” but I never really understood what they were talking about. In retrospect, I just didn’t have the ability to do the “listen to your heart” internal move, because the pipes were clogged by too much repressed gunk. I wish those soundbites had included a second sentence like “of course listening to your heart can be much easier said than done, so if it feels hard or unclear for you, here are some first steps to get started with, and be prepared for it to take you many hours (or years) to figure out what your heart is trying to say.”
This new mindset really shifted the way I related to my emotions. While I still often experience them as painful, it’s much less than I used to, and now I start from the assumption that they’re not “actually” painful or bad, and that the best thing to do with them is to figure out how to accept them, welcome them, and find the wisdom or beauty in them. Overall this feels a lot better—when I run into something stressful or hard, instead of just flailing around not knowing what to do about it, it feels more like I have some kind of sense of direction or overall orientation, which is really comforting and grounding.
I also noticed that a lot of these ways of thinking about emotional difficulty within myself were also useful metaphors for thinking about emotional dynamics between people. Just like resisting your own emotions is a common coping strategy but ultimately doesn’t work very well, resisting other people’s emotions is also a really common but damaging pattern, which I would guess is very involved in a lot of (most?) relational damage. For example, I realized that a big part of the root problem of the relationship that I had just ended was that both of us were missing the capacity to accept a bunch of each other’s emotions, which was something I hadn’t been able to articulate clearly at the time. I now think practices explicitly focused on welcoming each other’s emotions are a really valuable tool for nurturing relationships over time.
In fact, I started to notice that a lot of sticky problems—both in my personal life, but also the type that I ran into as a manager—were partly downstream of people resisting emotions of one type or another. Alice is hard to communicate with, because she frequently monologues about unimportant details, because she wants to prove she understands everything, because she has a bunch of stuck fear/resentment about not being taken seriously. Bob and Clara have a persistent disagreement about strategy, because Clara doesn’t care enough about Bob’s opinion to engage, because Bob was cruel to her once; Clara never complained because she’s avoiding the feeling of having been hurt by it. Dave’s team is underperforming but Erin, the exec sponsor, doesn’t want to manage him out, because she’s scared of the conflict and of making Dave’s reports, who like him, angry.
Of course, just because a problem is caused by stuck emotions doesn’t mean that unsticking them is the best way to solve it; but it was still a really useful lens to view what was going on.
The other shift that stuck around was in my relationships. I made a huge improvement in my friendships, which a few different things contributed to:
This also meant that my “friend type” changed—I cared more about emotional connection and less about intellectual connection. Luckily, even though I live in a really heady milieu, I was still able to find a lot of big-hearted people and gradually build up a set of close friends who are wonderful at both. So far, this is the change I’m the happiest about.
My dating life changed a bunch as well:
These changes have been really wonderful overall, but also kind of intense. Becoming much more emotionally aware solved a bunch of my problems, like wanting deeper friendships or not understanding why my relationship was unsatisfying. But it turns out winning that boss fight just made all the enemies level up. My old problems got replaced with horrible new problems, like that sometimes my newly deep friends and I would have conflicts, or that I would be more into the person I was dating than they were into me.
The part of my life where I feel the most mixed about the impact is work. About six months after my retreat, I got a pretty bad case of burnout and left my role managing a big team for a significantly less ambitious IC role. I don’t think the retreat was the main cause of my burnout—the main cause was that I didn’t have enough background in the area I was managing to have the type of impact that I wanted to, with a side helping of some difficult working relationships. But it turns out my new psyche had also gotten worse at repressing or avoiding emotion, and that made everything harder.
I think of repression as the emotional equivalent of technical debt or deferred maintenance: a way of avoiding an immediate cost, in this case feeling uncomfortable feelings, in exchange for paying a higher cost later to clean it up.6 My role exposed me to a constant stream of low-grade painful things, like people being disappointed or annoyed at me, me being disappointed or annoyed at other people, projects not going well, office snacks being replaced with worse snacks, and so on. With less ability to avoid or repress, I had to feel more of them fully as they came up, and that was really draining. It also required enough time and attention that I had to defer a bunch of maintenance on my personal life.
Even now that I feel like my energy levels have mostly recovered, I’m still not sure whether I want to go back to the center of the vortex. It’s not just that I would have to start deferring maintenance again; I’m also much more aware of a lot of maintenance I’d already deferred and really want to clean up—things like investing in friendships, like I mentioned above.
If I were only working toward my personal growth and happiness, I’d say this change was clearly good. My life feels much richer and more whole, and taking a less ambitious role forced me to release some layers of ego attachment to having a “shiny” job or career, which was deeply freeing. But… I also care a lot about my impact on the world, and I think the next few years will probably be a critical period where my work could be especially high-leverage. From that perspective, it’s sad to feel resistant to maxing out on work right now.
I feel pretty unsure about what to take away from all this. Here are some disconnected reflections.
I’m also just left with a lot of questions:
A draft reader asked what I would tell my past self, or someone like me, about this arc. Ultimately, I’d boil it down to:
There are probably a bunch of feelings that you’re refusing to welcome into your experience, and this is probably involved in a bunch of the things that are unsatisfying about your life and relationships.
You can improve this by gradually, in a safe context, paying loving attention to the uncomfortable parts, from a place of wanting to know and care for yourself rather than to fix yourself.
When that’s hard, remember that it’s not your fault. You’re just the rider; elephants gonna elephant. Let it go where it needs to and keep loving it as best you can.
Thanks to Alex Allain, Catherine Olsson, Elena Lake, Jess Ocean, Rahul Dalal, and Sasha Chapin for feedback on a draft of this post.
2026-04-24 08:00:00
A popular icebreaker in San Francisco these days is “How would you spend your life if AGI meant nobody needed to work?” For me, I think a surprisingly big part of the answer is a dorky-sounding kind of folk dance called contra dancing.
I started trying to answer that question by thinking: what are the things I do atelically—because I enjoy them for their own sake, not in pursuit of some longer-term goal? For me, a lot of that has to do with things that are (1) physically joyful, and (2) help me feel connected to other people.
My pitch for contra dancing is that among physically joyful and connecting activities, it’s one of the ones where it’s easiest to get to the point where it’s fun, and therefore one of the best to start out with. Many other forms of dance require weeks of lessons before you’re even encouraged to do it socially at all. By contrast, the format of contra dancing means that you can go to a half-hour beginner lesson before your first dance, and there’s a good chance you will be having a lot of fun by the end of the evening.
What’s more, the fact that it’s so easy to start having fun shapes its community and priorities, such that it has among the best vibes of any activity I do.
I first encountered contra in middle school. My mom ran an intentional community, and we had a housemate move in named Bree. Bree was obsessed with this thing called “contra dancing,” and every week she would try to convince me and our other housemates to come with her.
Which I absolutely refused. I was an extremely uncool middle schooler, and that meant I was terrified of doing anything that even whiffed of uncoolness, lest I give my classmates another reason to judge me. I was also deeply awkward; I’d never even been to a school dance and barely talked to girls. But Bree was persistent, and one of our other housemates got hooked, and eventually I was intrigued.
By then, though, I was dug in as a contra hater, and I was scared that if I admitted I had changed my mind, my housemates would make fun of me. So I kept refusing.
Finally, my housemate Thomas, who was even more of a skeptic than I was, told Bree that he would only go if I went, presumably so that she would stop bugging him and bug me instead. Aha—my golden opportunity! I could pass off my change of heart as a prank on Thomas. “Okay, sure! It’s a deal!”
Bree and I showed up at the Concord Scout House one Thursday evening and jumped into the next dance. It was an unusually complex square dance, and I got confused—in fact, so confused that my entire square ended up giving up halfway through.1
I was mortified. Not only was I doing a deeply uncool activity, I was the least cool person there, ruining it for all the slightly less uncool people with my incompetence and lameness.
Except that the other dancers didn’t seem to see it that way. Instead of resenting me or making fun of me, they said things like “Gosh, that one was really tricky!” and “Sorry, that’s really not what it’s usually like!” and “Please don’t give up, try a few more dances! Want to dance with me?”
I tried some more dances, I didn’t cause any more collapses, and by the end of the night I was overflowing with exhilaration and joy. I went back the next week, and the week after that. I went to the twelve-hour Snow Ball and then the weekend-long Flurry Festival. I got to feel cool for the first time in my life when people started being excited to dance with me, and even cooler when some of them asked me on dates. It was a huge part of my life for a while, and although I’m now dancing at maybe a quarter of my peak intensity, it’s still one of my most joyful and treasured things I do.
This happens to about one in ten people I take contra dancing: something clicks and it becomes a big part of their life.
So what exactly is contra dancing?
When people ask me this I often feel stuck, because describing the mechanics of a contra dance doesn’t really capture its essence or why it’s fun, but without understanding the mechanics, the essence doesn’t really make sense. So I’ll try both. But you have to promise to read through to the essence part, and not just bounce off if the mechanics sound silly.
Mechanically: you show up to the dance hall. You ask someone to dance, or they ask you. You join a long line (“set”) of other couples and take hands in a four-person group with one adjacent (“neighbor”) couple. A caller stands at the top of the dance hall and does a “walk-through” of the dance you’re about to do, calling out a series of figures (“circle left three places,” “do-si-do your neighbor,” etc.) At the end, you’ve moved up or down the line, and you’re ready to do the same thing with some new neighbors coming at you.
Next to the caller is a live band. (They probably sound a bit like this.) The pianist plays four potatoes and the fiddler launches into a reel. The caller calls out the figures for the first few times through the dance, then drops out as the dancers get into flow.
It looks a bit like this video, although I don’t know how much this will transmit the vibe, since contra is a lot more fun to do than it is to watch:
To me, the essence of contra dancing is about flow, joy, and community.
You can’t really tell from watching, but a lot of what makes for good contra dancing is learning how to trade momentum back and forth (“share weight”) with other dancers so that each figure flows seamlessly into the next one. When you get this right, it feels amazing. Subtle changes in how your partner holds your hand cue you into the next figure. The dance becomes effortless. You can turn your brain off and just do what the giant dancing super-organism invites you to do.
It’s also physically joyful. The core figure of contra dancing is called the swing, in which you and your partner take a waltz-like hold and pivot around a shared center. Done right, it feels like a cross between flying and a world-class hug. Even outside of the swing, the shared weight, smooth momentum, and twirling “flourishes” will make you feel weightless, graceful and deeply connected to the music and the other dancers.
Lots of kinds of dance feel flowy and exhilarating when done well. What makes contra different is how easy it is to get there. Most forms of dance require weeks of lessons before they get fun. In contra, all you need to do is show up for one beginner lesson half an hour before the dance starts.2 Of course, there’s plenty to learn after that—improving your swing technique, learning how to share weight, and where to put flourishes for the best joy and flow—but all of that is for getting you from a 8/10 to an 11/10 on the fun scale; getting to an 8 is pretty straightforward.
So contra makes it easy to have a baseline level of fun dancing with anyone. And because it’s a group dance, you end up feeling connected to your entire set, not just your partner. I think those two things are behind my other favorite part of contra dancing, which is how friendly and welcoming the community is.
Many kinds of dance are a bit snooty—the experienced dancers look down on newbies and try to avoid dancing with them. By contrast, my experience at my first dance, where I caused my square to crash and burn and was met with apologies and “I hope you’ll give it another shot,” is typical for contra. A lot of contras explicitly ask experienced dancers to dance with newcomers. It’s just hard to be snooty when you’re having so much fun! You want to share it with everyone.3
As draft reader Chloe put it: “I think in many ways, your story of your first dance is the heart of it—you can’t do it wrong. Or even if you do, it somehow leads to more love.”
In my opinion, this makes contra dancing one of the best entry points to dance:
While it’s structured enough to be beginner-friendly, there’s also enough room for improvisation and technique to give it a lot of depth. This makes it a great on-ramp to other dances and movement practices. When I started contra dancing I had a lot of fear and blocks about improvised dancing (for example, I didn’t feel comfortable dancing at standard American high school/wedding style dances), but recently I tried out fusion and contact improv and had fun at both. It’s pretty common for people to use contra as a gateway into more difficult forms of dance.
Most importantly, though, it’s just incredibly joyful on its own! It’s the only activity I know of where I’ve had multiple friends mention that every time they go, their cheeks hurt from smiling so much.
Beyond just fun, multiple draft readers independently commented that contra dance is a precise opposite of many things that bother them about… the rest of life:
Much of my life happens on a screen in motionless silence; contra is as three-dimensional, movement- and sound-filled as you can get.
The default mood of a lot of spaces is a sort of ironic detachment.4 The default mood of contra dancing is earnest joy.
In everyday life it’s easy to end up atomized and isolated. At a contra, everyone does the same steps and makes the dance together; it’s deeply communal.
In a lot of social contexts (especially in San Francisco), I often feel like I’m being “sized up” for how interesting or important I am. At most contras, people are just happy I’m there.
Many things I do (work, choral music, blogging…) reward excellence above almost everything. Contra welcomes imperfection: we’d rather have an amateur live band than recorded professionals, and don’t believe in more than half an hour of organized teaching.
This makes it a grounding and nourishing antitode to a lot of everyday stressors. When I was so drawn to it in middle school, I don’t think it was just about the fun: on some deep level it was very good for me.
If I’ve gotten you excited enough to try contra, here’s what you should do:
Have fun! I hope you smile so much your cheeks hurt.
Thanks to Jeff Kaufman, Alex Allain, Chloe Lubinski, and Jessie Brown for commenting on a draft of this post.
Further reading/listening/other consumption:
2025-04-19 08:00:00
I’ve been thinking recently about what sets apart my coworkers who’ve done the best work.
You might think that the main thing that makes people really effective at research or engineering is technical ability, and among the general population that’s true. Among my Anthropic coworkers, though, we’ve restricted the range by screening for extremely high-percentile technical ability, so the remaining differences, while they still matter, aren’t quite as critical. Instead, people’s biggest bottleneck eventually becomes their ability to get leverage—i.e., to find and execute work that has a big impact-per-hour multiplier.
For example, here are some types of work at Anthropic that tend to have high impact-per-hour, or a high impact-per-hour ceiling when done well (of course this list is extremely non-exhaustive!):
I think of finding high-leverage work as having two interrelated components:
Without taste, you’re likely to work toward the wrong thing. Without agency, even if you work toward the right thing, you’re likely to get nowhere.
How can someone improve at these? Mostly, I think, by practicing: there’s no substitute for good feedback loops with reality. So maybe the most important takeaway here is that you have permission to try to exercise good taste and high agency! But below are some more specific pieces of advice that have helped me improve on these dimensions.
One of the easiest ways to get more leverage is to take a goal you’re already trying to accomplish, and figure out a better way to accomplish the same thing. (For example: changing your experiment design to be more directly relevant to the high-level question; finding an 80/20 way of building a tool; just deciding not to do something entirely; etc.) In order to do this, you need to keep careful track of the high-level context and priorities that your specific project is aimed at, so that you can understand and judge the trade-offs.
Obviously, whoever’s supervising your project will make an attempt to point you at the most effective way of achieving the goal that they can think of. But finding the most effective way of doing something takes a lot of time and attention, they probably have a lot of other things to do, and they also have much less detailed context than you, so they’re liable to miss things!
For example, when I did a work trial at Anthropic in late 2022, I was assigned the task of building a custom scheduler for our compute cluster to fix some unfortunate behaviors in the default scheduler that were making researchers’ lives hard. But after seeing the team work for a week and thinking about the system design, I started to worry that this project would end up imposing a high maintenance burden on the team that owned the cluster, which was already overloaded, and I ended up suggesting that we postpone it. It turned out that second-order effect would have made this project net-negative for the root goal of “keep the clusters working well!”
A counterintuitive fact about the highest-leverage projects is that they’re often not obviously high-leverage to most people in advance (because if they were, they would already have been done a long time ago). That means people are often skeptical of the value of pursuing them.
That skepticism can be for a couple reasons (in the real world, most projects have some mix of both going on):
A personal example: shortly after I joined Anthropic’s inference team, a couple folks on the team proposed completely rewriting our inference service codebase, because they felt the current version was overcomplicated. I was somewhat skeptical of this, based on the standard software engineering heuristic of “most rewrites fail and most people are over-optimistic about how long they will take,” although I didn’t push back very hard because I knew I didn’t have much context. It turned out that the rewrite took about a week, was an immediate integer-multiple efficiency improvement, and made it much easier to make further efficiency improvements. I’m glad that people didn’t listen to my skepticism!
One tactic for addressing this dynamic is that instead of asking people for approval to go do something, you can just tell them what you intend to do (implicitly giving them space to object or course-correct if they feel strongly).
Of course, the same “high leverage projects are non-obvious” phenomenon also means that some of your self-driven high-impact project attempts will probably fail, because you misjudged their impact or difficulty. Because of this, you should think of them as bets that might or might not pay off, and—at least until you’ve proven your ability to make good bets over fairly long time horizons—it’s best to keep these as part of a portfolio with low-risk projects as well, to avoid the situation where you bite off a single high-risk project, it doesn’t pan out, and people lose trust in your ability to pick your own projects.
A common trait of high-agency people is that they take accountability for achieving a goal, not just doing some work.
There’s a huge difference between the following two operating modes:
Mode 1 makes you a leaky abstraction—if your project is critical, someone else needs to be constantly monitoring it and figuring out how to resolve blockers. My concept handle for being in mode 2 is “making success inevitable,” because “inevitable” is the bar where other people can stop spending substantial fractions of mental energy on worrying about the project.
People who can be trusted to make something inevitable are really rare, and are typically the bottleneck for how many different things a team or company can do at once. So if someone else is responsible for making your project inevitable, you’re consuming some of that scarce resource; if you’re the one making your own projects inevitable, you’re a producer of that resource, and you’re helping unblock a key constraint for your team.
(Of course in practice you will never achieve full inevitability, but getting closer to it still makes a huge difference!)
I wrote above that you should expect high-impact projects to be non-obvious because if they were obvious, they’d have been done already. This points to another interesting dynamic, which is that it’s quite rare for different people’s “zone of best taste” to overlap very much. Instead, the quality of most people’s taste is highly idiosyncratic and area-specific, where areas can be as localized as e.g. “language model personality design” or “what blog post titles will get upvoted on Hacker News” (one of my own less-useful areas of good taste…)
For this reason, an important signal to keep track of is: where is your taste the best?
I’ve noticed a lot of people underestimate their own taste, because they expect having good taste to feel like being very smart or competent or good at things. Unfortunately, I am here to tell you that, at least if you are similar to me, you will never feel smart, competent, or good at things; instead, you will just start feeling more and more like everyone else mysteriously sucks at them.
For this reason, the prompt I suggest here is: what does it seem like everyone else is mysteriously bad at? That’s probably a sign that you have good taste there.
It’s okay if this prompt doesn’t immediately yield anything; you might just be on a team with a lot of really good people, where you don’t have a really unique angle on anything yet. Even so, a weakened version of this question—where does it seem like the most people are being the least competent?—is a useful gradient signal!
One way of thinking about taste is that it’s about the quality of your predictive models and search heuristics. If I design the experiment this way, what will I find? If I design the tool this way, how easy will it be to use? If I write the doc this way, how much will it resonate with people?
Doing enough search and prediction to come up with great ideas takes time. The first domain that I got some degree of taste in was software design, and I remember a pretty clear phase transition where I gained the ability to improve my designs by thinking harder about them. After that point, I spent a lot of time iterating on many different design improvements—most of which I never implemented because I couldn’t come up with something I was happy enough with, but a few of which turned into major wins.
The easiest way to improve at this is just to try it! Whenever you’re debating what to do, explicitly ask yourself “what do I predict will happen if I choose option A?” and try to unroll the trajectory. Even if you think you’re already intuitively predicting the results of your choices, I’ve found it helps surprisingly much to be explicit—one of my manager role models asks me this (“what do you think will happen?”) every time I ask him for advice and it’s kind of silly how often it helps me realize something new. (For bonus points, revisit your predictions afterwards.)
Things that I’ve found benefit from a lot of thinking time:
(See also: Think real hard. Although if you’re someone whose natural failure mode is to overthink things, it’s possible you should reverse this advice.)
If taste is about the quality of your predictive models and search heuristics, it’s important to wring out every possible update to these from the data that you get.
For that reason, many of the most effective people I’ve worked with also do the most metacognition, i.e., reflecting on their own (and their team’s) work and thought processes, and figuring out how to improve them. They’re often the people who are most likely to identify improvements to our processes or mental models—things like:
Often, they don’t just do their own metacognition but also help drive “group metacognition” by sharing these reflections with the team, scheduling retrospectives, etc. Even if each of the lessons here is small individually, they compound over time to help people and teams become much more effective.
My best habit for encouraging myself to metacogitate more is a weekly review. The format and typical outcomes of my reviews have evolved a lot since I wrote that, but I still do them and find them extremely valuable for helping me improve at whatever I’m currently focused on improving at!
(See also / further reading: Chris Olah’s Research Taste Exercises)
2025-04-01 08:00:00
This post was adapted from an internal doc I wrote at Wave.
Welcome to being a manager! Your time-management problem just got a lot harder.
As an IC, you can often get away with a very simple time-management strategy:
As a team lead, this isn’t going to work, because much more of your work is interrupt-driven or gets blocked for long periods of time. One-on-ones! Code reviews! Design reviews! Prioritization meetings! Project check-ins! All of these are subject to an external schedule rather than being the type of thing that you can push on in a single focused block until it’s done.
Being a team lead means three big changes for your time management:
You no longer have a single most important thing. You’ll have to learn how to juggle competing priorities.
Your most important responsibility is for your team’s output, not your personal output. That means that individual engineering work goes last in your list of potential most important things.
You’ll need to start spending some of your time on a manager’s schedule:
There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.
Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.
Here’s some advice on how to cope with those changes.
Your responsibilities to your team will take time, and even more importantly, attention. That means you’ll be a lot less productive on IC work than you have been in the past—especially at first while you’re finding your legs. Additionally, your time will be less predictable week-to-week as you might have to spend an unknown amount of time responding to “inbound” work.
For the first few months, you should treat any individual engineering work that you get done as a bonus. Even after that, you should expect to have something like 10-20% less individual output per engineer you manage, depending on how experienced you are, they are, etc., and with substantial week-to-week variance.
To mitigate this, my rule for myself has been to make sure that my IC work is important but not urgent—i.e. that nobody will be sad and no plans will be derailed if I end up having to spend the next week firefighting instead of pushing it forward.
For honing my intuitions about how much I can actually expect to accomplish, I’ve found time tracking very useful (see How time tracking helped me be a better manager and I apparently got 50% better at my job last month).
A corollary of the above is that it becomes very important for you to prioritize what to work on, both on an hour-to-hour cadence and on a larger timescale.
It’s not possible to write down a full algorithm for prioritizing in a blog post—that’s why they pay us the big bucks—but here are some heuristics for which things are most worth prioritizing:
One of the most important types of “work that increases your or your team’s future bandwidth” is delegating things. This is something entire books have been written about, but here’s how to avoid a few common delegation pitfalls for new team leads:
Negotiate how hands-on to be. Effective delegation means finding the right balance between micromanaging, and throwing your report to the wolves. The stereotype is that new managers often micromanage, but at Wave, I’ve noticed that new managers often err on the side of undermanaging, or being too hands-off, perhaps out of a desire to signal that they trust their reports.
If you’re unsure, it’s good to have an explicit conversation with the person you’re delegating to about how much support they want. E.g. “do you want to do the design for this feature yourself, have me do the high-level and fill in the details, or have me write the entire design doc?”
Calibrate to your team members’ task-relevant maturity, or how capable they are of independently doing a particular type of task. A senior engineer should be able to design most features independently (with review), but give the same design task to a junior engineer and they’ll probably flail around and make no progress. You should be maintaining a mental map of each of your team members’ strengths and weaknesses—and updating it over time as you help them improve.
Delegate ahead of future growth. Your team’s workload is going to increase over time, so even if you don’t feel like you have too much work to do right now, you probably will in the future, unless you currently feel underutilized. You should aim for a workload where in the steady state, you feel like you have some slack capacity.
Delegate “stretch projects” to help your team level up. Getting enough slack might require you to delegate work that no one else on your team can currently do. Take your mental strengths-and-weaknesses map, ask yourself what the most important growth directions for each of those team members are, and figure out how to give them work that stretches them in that direction. Note that these delegations will probably require more frequent monitoring, since your reports will have less task-relevant maturity on their stretch projects!
Despite your best efforts to follow the above advice, there will probably come a time when you feel very stressed about the amount of work on your plate. When that time comes, here’s what to do:
If you’re not careful, it’s easy to fill your entire calendar with meetings, Slack, etc. and have no time for deep work. With careful planning, you can avoid this by “batching” all your distractions to particular times of day.
There are lots of tactical tips for doing this; I catalogued some that work for me in Tools for keeping focused.
One tech-lead-specific one that I’ll add is batching meetings: I schedule all my meetings back-to-back on Tuesdays and Thursdays to leave the rest of the week as free as possible for deep work.
2025-03-16 08:00:00
My few most productive individual weeks at Anthropic have all been “crisis project management:” coordinating major, time-sensitive implementation or debugging efforts.
In a company like Anthropic, excellent project management is an extremely high-leverage skill, and not just during crises: our work has tons of moving parts with complex, non-obvious interdependencies and hard schedule constraints, which means organizing them is a huge job, and can save weeks of delays if done right. Although a lot of the examples here come from crisis projects, most of the principles here are also the way I try to run any project, just more-so.
I think excellent project management is also rarer than it needs to be. During the crisis projects I didn’t feel like I was doing anything particularly impressive; mostly it felt like I was putting in a lot of work but doing things that felt relatively straightforward. On the other hand, I often see other people miss chances to do those things, maybe for lack of having seen a good playbook.
So here’s an attempt to describe my playbook for when I’m being intense about project management.
(I’ve described what I did as “coordinating” above, but that’s underselling it a bit; it mattered a lot for this playbook that I had enough technical context, and organizational trust, to autonomously make most prioritization decisions about the project. Sometimes we instead try to have the trusted decisionmakers not be highly involved in managing execution, and instead farm that out to a lower-context or less-trusted project manager to save the trusted decisionmaker time, but IMO this is usually a false economy for projects where it’s critical that they be executed well.)
For each of the crisis management projects I completely cleared my schedule to focus on them, and ended up spending 6+ hours a day organizing them.
This is a bit unintuitive because I’m used to thinking of information processing as basically a free action. After all, you’re “just” moving info from place to place, not doing real work like coding, right? But if you add it all up—running meetings, pinging for updates, digesting Slack threads, pinging for updates again, thinking about what’s next, pinging for updates a third time, etc.—it’s surprisingly time-intensive.
Even more importantly than freeing up time, clearing my schedule made sure the project was the top idea in my mind. If I don’t do that, it’s easy for me to let projects “go on autopilot,” where I keep them running but don’t proactively make time to think through things like whether we should change goals, add or drop priorities, or do other “non-obvious” things.
For non-crisis projects, it’s often not tenable (or the right prioritization) to spend 6+ hours a day project-managing; but it’s still the case that you can improve execution a lot if you focus and make them a top priority, e.g. by carving out dedicated time every day to check statuses, contemplate priorities, broadcast updates, and so on.
A specific tool that I’ve found critical for staying oriented and updating quickly is a detailed plan for victory, i.e., a list of steps, as concrete as possible, that end with the goal being achieved.
The plan is important because whether or not we’re achieving the plan is the best way to figure out how well or badly things are going. Knowing how well or badly things are going is important because it tells me when to start asking for more support, cutting scope, escalating problems, and otherwise sounding more alarms. One of the most common megaproject failure modes is to not freak out soon enough, and having a concrete plan is the best antidote.
As a both positive and negative example of this, during a recent sprint to release a new implementation of a model, we took a detailed accounting of all the work we thought we had to do to launch.
As the above example shows, having a plan can’t completely save you if you underestimate how long all the steps in the plan will take. But it certainly helps! My sense is that the main things that would have helped even more in the above case were:
OODA stands for “observe, orient, decide, act”—in other words, the process by which you update your plans and behavior based on new information.
Most of the large projects I’ve worked on have been characterized by incomplete information:
In fact, I’d make a stronger claim: usually getting complete information was the hard part of the project, and took up a substantial fraction of the overall critical-path timeline.
For example, let’s take a recent project to kick off a training run. The critical path probably looked something like:
Practically all of these steps are about information-processing, not writing code! Even the step where the compute partner debugged the problems on their side was itself constrained by information processing speed, since there were tens of people working on the debugging effort and coordinating / sharing info between them was difficult. Overall, the project timeline was strongly constrained by how quickly information could round-trip from our compute partner’s large-scale debugging effort, through their tech lead, me, and Anthropic’s large-scale debugging effort.
This pattern generalizes to most projects I’ve been a part of, and as a result, one of my most productive project management habits is to try to run the fastest OODA loop that I can.
A few specific things that I’ve found help:
It’s not just enough for me personally to be running a fast OODA loop—in a large group, everyone needs to be autonomously making frequent, high-quality, local prioritization decisions, without needing a round-trip through me. To get there, they need to be ambiently aware of:
I’ve usually found that to create the right level of ambient awareness, I have to repeat the same things way more often than I intuitively expect. This is roughly the same “communicate uncomfortably much” principle above, but applied to broadcasts and not just 1:1 conversations with people.
For example, although the first team I managed at Anthropic started with a daily asynchronous standup, we found that synchronous meetings were much more effective for creating common knowledge and reorienting, so we moved to a twice-weekly synchronous standup, which probably qualified as “uncomfortably much” synchronous communication for Anthropic at the time.
Once a project gets over maybe 10 people, I can’t track everything myself in enough detail to project-manage the entire thing myself. At this point, it becomes critical to delegate.
Here I mean delegating the project management, not just the execution (that’s what I’d be delegating to the first 10 people). This is the point where I need other people to help split up the work, monitor and communicate progress, escalate blockers, etc.
A few things I try to keep in mind when delegating project management:
One of my favorite things to make delegation easier is to keep goals simple—if they can fit in a Slack message while still crisply describing a path to the desired end state, then the people working on the goal will be much more able to prioritize autonomously, and point their work at the real end goal rather than doing something that turns out to be useless for some reason they didn’t think about.
“Keep goals simple” doesn’t have to mean “do less”—the best way to keep goals simple is to find the latent structure that enables a clean recursive decomposition into subgoals. This often requires a deceptive amount of work—both cognitive and hands-on-keyboard—to identify the right intermediate goals, but I’ve found that it pays off immensely by clarifying what’s important to work on.
Some of my favorite memories of Anthropic are of helping out with these big projects. While they can be intense, it’s also really inspiring to see how our team comes together, and the feeling of being part of a big team of truly excellent people cooking something ambitious together can be really magical! So I try to enjoy the chaos :)
Here’s the internal doc I share with folks on my team who are getting into being responsible for large projects.
So you’re the DRI of a project (or part of one). Concretely, what do you do to “be DRI”?
This doc is my suggested “starter kit” answer to that question. The habits and rituals described here aren’t perfect for every situation, but they’re lightweight and broadly helpful. I suggest you use them as a starting point for iteration: try them out, then adjust as necessary. This is an SL init; the RL is your job :)
The goal is to help you do your job as DRI—
—without adding too much overhead:
(Note: being DRI will still unavoidably add some overhead—e.g. you’ll have to track what other people are doing, delegate work, unblock people, set and communicate goals, etc. The goal is specifically for the process/paperwork to be minimal.)
You should schedule at least one 30-minute weekly meeting with everyone working on the project.
The goal of this meeting is to (1) be a backstop for any coordination that needs to happen and didn’t happen asynchronously; (2) be an efficient way to create common knowledge of goals, updates, etc.; (3) help you track whether things are going well.
It’s really helpful for discoverability and wayfinding to have a single “master doc” with all the most important info about a project. As you loop more people in, they can read the doc to get up to speed. And anyone who thinks “I wonder how X is going” can stop by there to find out.
Create a doc for your workstream with:
If it’s part of a larger project, your doc should be nested within the larger project’s working doc.
If this ends up being too much for one doc, you can fork these out into sub-docs (esp. running notes and updates).
Thanks to Kelley Rivoire for many thoughtful comments on a draft!
2024-07-21 08:00:00
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.
