Some mistakes I made as a new manager

This post was adapted from a “management roundtable” I gave at Anthropic.

I had an unusually hard time becoming a manager: I went back and forth three times before it stuck, mostly because I made lots of mistakes each time. Since then, as I had to grow my team and grow other folks into managing part of it, I’ve seen a lot of other people have varying degrees of a rough time as well—often in similar ways.

Here’s a small, lovingly hand-curated selection of my prodigious oeuvre of mistakes, and strategies that helped me mitigate them.

The trough of zero dopamine

The first thing I noticed about being a manager was that I wasn’t sure whether anything I was doing was useful.

As an engineer, I had a fast feedback loop—I could design something, code it, test it, show it to coworkers, ship it and see users happily using it all within a day or two.

Managing doesn’t have that kind of feedback. If I gave someone helpful advice in a one-on-one, at best they might mention it offhandedly three weeks later; more typically, they might forget to, and I’d never know. Without being able to tell whether I was doing anything useful, it was hard for me to stay motivated.

Gradually, over my first year, I built up better self-evaluation instincts. Today, if I give someone advice, I can usually guess right away whether it’s useful—not perfectly, of course, but well enough that I can feel good about my day-to-day output.

But those self-evaluation instincts took time to develop. In the mean time, I went through a demotivated slump, and I’ve seen lots of other new managers go through it too.

Three strategies helped me through it:

Staying on the critical path

I started managing with only a few reports, so it was easy for me to tell myself that I still had time to code. In principle that was true. What I didn’t have was enough attention to split between two things:

Like many people, I have most of my best ideas in the shower…. The time when it was most constraining was the first time I became a manager. I only had a few reports, so managing them wasn’t a full-time job. But I was very bad at it, and so it should have been what I spent all my shower insights on.

Unfortunately, I was spending my non-management time on programming. And even if I tried to use my showers to think about my thorny and awkward people issues, my mind somehow always wandered off to tackle those nice, juicy software design problems instead.

This was extra-bad when the programming was urgent: I’d end up caught between, say, disappointing our operations team by not shipping a critical tooling improvement, or letting down my own team by half-assing planning and letting them work on unimportant things. I found these periods really stressful.

Eventually, I decided that I’d only allow myself to work on programming projects if nobody else cared when they shipped—say, cleaning up some non-blocking tech debt, or doing small bits of UI polish. If I had spare time after getting through my more important management work, I could pick up one of those projects, but if I had a busy week and had to put it on hold, nothing bad would happen.

(See also: Attention is your scarcest resource, Tech Lead Management roles are a trap.)

Managing the wrong amount

I read a bunch of management books that warned me against micromanaging my reports, so I resolved not to do that. I would give my team full autonomy, and participate in their work only by “editing” or helping them reach a higher quality bar. “These people are smart,” I thought. “They’ll figure it out, or if they get stuck they’ll ask me for help.”

That plan fell apart almost immediately, when I asked a junior engineer to write a design doc for a new feature. He did his best, but when he came back a few days later, it was clear he was flailing—he didn’t understand what level of abstraction to write at, had a hard time imagining the future the pros and cons of various decisions, and didn’t know how much weight to put on the ones he did identify.

Eventually we decided that I would write the design and he would implement it. After that, the project went much better.

In hindsight, it was silly of me to assume he’d ask me for enough help. He may not have realized that what he was experiencing was the feeling of being out of his depth—and even if he had, he might (reasonably!) have been reluctant to ask for more support from me, if he thought I’d expected him not to need it.

Instead of “don’t micromanage,” the advice I wish I’d gotten is:

  1. Manage projects according to the owner’s level of task-relevant maturity. i.e. how experienced and autonomous they are at doing that particular task. Even people at a similar level of experience can have different task-relevant maturities for different skills: one senior engineer might be able to take a new system from design to production on their own but struggle to write understandable documentation, while another might flail around if given a project with ambiguous scope, but be unstoppable at chasing down tricky bugs.

  2. People with low task-relevant maturity appreciate some amount of micromanagement (if they’re self-aware and you’re nice about it).

One thing that really helped me calibrate on this was talking about it explicitly. When delegating a task: “Do you feel like you know how to do this?” “What kind of support would you like?” In one-on-ones: “How did the hand-off for that work go?” “Is there any extra support that would be useful here?”

(See also: Situational Leadership theory.)

Procrastinating on hard questions

Being a manager put me in the line of fire for a lot of emotionally draining situations—most often, for example, needing to give people tough feedback or let them go. At the beginning, I just tried to avoid thinking about these: if someone wasn’t performing well, I’d ignore it or convince myself they were doing a good enough job.

Fortunately, my manager was exceptional at “staring into the abyss” and convincing other people to do the same. He coached me through my first couple tough situations, and each time I realized afterwards that I felt relieved of a huge burden, and having the “abyss” resolved made me way happier. After I internalized that, I was much happier to spend time thinking about things that made me uncomfortable.

Staring into the abyss as a core life skill suggests some strategies for getting better at this:

Another abyss-staring strategy I’ve found useful is to talk to someone else. One reason that I sometimes procrastinate on staring into the abyss is that, when I try to think about the uncomfortable topic, I don’t do it in a productive way: instead, I’ll ruminate or think myself in circles. If I’m talking to someone else, they can help me break out of those patterns and make progress. They can also be an accountability buddy for actually spending time thinking about the thing.

… One solution to the timing problem is to check in about your abyss-staring on a schedule. For example, if you think it might be time for you to change jobs, rather than idly ruminating about it for weeks, block out a day or two to really seriously weigh the pros and cons and get advice, with the goal at the end of deciding either to leave, or to stay and stop thinking about quitting until you’ve gotten a bunch of new information.

Indefinitely deferring maintenance

“Deferred maintenance” means postponing repairs or upkeep for physical assets like buildings, equipment, infrastructure, etc. It’s often done by, e.g., underfunded transit agencies to make up for going over budget in other areas. But maintenance is needed for a reason—unmaintained infrastructure degrades more quickly, and is more expensive to fix in the long run.

As a new manager in a quickly growing team, I always felt like I was “over budget.” One-on-ones! Hiring! Onboarding! Code reviews! Design reviews! Incident response! Postmortems! There was always enough time-sensitive work for three of me. That meant that I’d “postpone” the managerial equivalent of maintenance over and over:

Eventually I realized that I needed to have slack by default. It’s okay if I sometimes defer maintenance during much-busier-than-usual periods, but only if I’m honest with myself about what “much busier than usual” actually means. If it’s not one of my 4-8 worst weeks of the year, I should be spending some time on long-term investments.

Of course, this requires me to manage my workload well enough that it’s default below my capacity. I could still improve at this, but I’ve found a trigger-action-plan for when I feel overwhelmed that usually does the job:

It was really helpful for me to realize that it was okay for me to change or discard priorities if I did it right—people are usually quite sympathetic as long as I warn them in advance (e.g. “sorry, I have to slip this deadline / give up on this due to [whatever more important thing]”), so that it doesn’t come as a surprise and they can change their plans or push back.

(See also: Slack.)

Angsting instead of asking

I care a lot about my coworkers’ opinions of me. About 95% of the time this is a force for good: it makes me less likely to do low-integrity things, go on power trips, etc. The other 5% is when I, e.g., say something to Dave the product manager that comes out wrong and spend the next six weeks stressed about whether Dave is secretly steaming at me.

I had a very illuminating conversation about this with Drew at one point:

Ben. I’m worried I pissed off Dave the product manager by saying something that came out wrong.

Drew. Have you asked him whether you pissed him off?

Ben. facepalming I should have known you were going to say that.

(Since then, I’ve been on the other side of this exact conversation with most new managers I’ve supported! So if you feel silly for not asking them yet, you’re in excellent company.)

If you’re worried that you made someone upset and you ask them about it, one of three things can happen:

This also applies to most other things you might be worried about. Is my team’s strategy good? Does this recurring meeting add value? Is this new hire spinning up fast enough? Just ask people!

If you’re worried that they won’t be honest if you ask them directly—maybe because you barely know each other or there’s a large power imbalance—you can ask for a backchannel from your manager or theirs. Similarly, having your own manager do skip-level 1:1s with your reports can give you more perspective and confidence that your team is happy with you.

Closing thoughts

There are a few core reasons that being a new manager is hard:

Because of that, you should expect to make a bunch of mistakes while you’re starting out. But it’s still useful to know a basic set of pitfalls to avoid, so that you can spend your quota on new, exciting types of mistakes instead :)


email me replies

format comments in markdown.

Your comment has been submitted! It should appear here within 30 minutes.

Amazing, very much what I experienced being a manager for ~6 months before bailing out back to IC.

email me replies

format comments in markdown.

Your comment has been submitted! It should appear here within 30 minutes.


You missed a potential fourth outcome of asking someone if you’ve made them upset: They respond that you didn’t, but you actually did and are now harboring unseen resentment.

email me replies

format comments in markdown.

Your comment has been submitted! It should appear here within 30 minutes.

Michael Kozakov

Hah I’m a new manager at Cohere, and know a bunch of people from Wave. This was very relatable, thank you!

email me replies

format comments in markdown.

Your comment has been submitted! It should appear here within 30 minutes.


Take a look at aufstragstatik in management context.

email me replies

format comments in markdown.

Your comment has been submitted! It should appear here within 30 minutes.


I really appreciate this post Ben.

One question I have is how this transition to being a new manager is the org structure involved in the move. Specifically, in this transition were you managing individuals who were also predominantly managers?

I ask as that was for me a second phase transition in terms of the nature of work at the scale of “IC-Manager”, particularly insofar as the nature of feedback, feedback mechanisms, agency, and control needed to be yet again abstracted to account for their work being predominantly managerial in nature as well.


This was just about transitioning to line manager! I could probably write a whole separate post on “some mistakes I made as a new manager-of-managers” :)

email me replies

format comments in markdown.

Your comment has been submitted! It should appear here within 30 minutes.


Thanks so much for this - I have often managed 1-2 people in previous roles but am now starting to manage 4 people while also still having some object level work to finish up and it’s such an exciting but entirely new challenge! This was really helpful, especially to pick out things for me to talk over with a more experienced manager.


Hey Juju!

email me replies

format comments in markdown.

Your comment has been submitted! It should appear here within 30 minutes.


This was ridiculously spot on. Thank you so much for putting into words what I’ve been experiencing the last 12 months since making the move from Engineer to Engineering manager. It’s good to know that it’s “a thing” and also comforting to know that some of the strategies you suggested and realisations you arrived to I too have implemented and realised. Management is a different beast for sure but from my little experience can be very satisfying, just in a different way to engineering. Thanks again.

email me replies

format comments in markdown.

Your comment has been submitted! It should appear here within 30 minutes.