本文作者分享了自己成为管理者后的一些经验教训，包括如何克服初期缺乏成就感，如何管理时间和精力，如何根据员工成熟度进行管理，如何处理棘手问题，以及如何避免拖延维护工作等。作者还分享了一些应对这些挑战的策略，例如主动寻求反馈、建立其他兴趣爱好、明确管理目标、进行定期沟通等。

😁 **克服初期缺乏成就感**：作者在刚成为管理者时，由于缺乏明显的反馈，很难感受到自己的工作价值，并因此感到沮丧。作者通过主动寻求反馈、建立其他兴趣爱好以及与经理进行沟通，最终克服了这一问题。 作者发现，与经理坦诚沟通自己的感受，能够获得更长远的视角和鼓励；向团队成员寻求反馈，能够更深入了解自己的工作效果；而培养其他兴趣爱好，能够帮助作者在工作中获得更多乐趣和成就感。 作者建议，新晋管理者可以通过主动寻求反馈，建立其他兴趣爱好以及与经理进行沟通来克服初期缺乏成就感的困境。

🤔 **合理分配时间和精力**：作者在成为管理者后，发现自己难以平衡管理工作和编码工作，并因此感到压力。作者最终决定，只在非紧急情况下进行编码工作，并将更多时间投入到管理工作中。 作者认为，时间和精力是宝贵的资源，需要合理分配。在管理工作中，需要优先处理重要的事情，例如团队成员的成长、项目规划等。而对于非紧急的编码工作，可以等到完成管理工作之后再进行。 作者建议，新晋管理者要明确管理工作的重要性，并合理分配时间和精力，避免过度投入到非紧急的工作中。

🤯 **根据员工成熟度进行管理**：作者最初认为，应该给予团队成员充分的自主权，避免过度干预。然而，作者发现，对于一些经验不足的团队成员来说，过度放手反而会影响工作效率。 作者意识到，管理需要根据员工的成熟度进行调整。对于经验丰富的团队成员，可以给予更多自主权；而对于经验不足的团队成员，则需要提供更多的指导和支持。 作者建议，新晋管理者要根据员工的成熟度进行管理，不要过度放手，也不要过度干预，要找到合适的平衡点。

😩 **勇于面对棘手问题**：作者在成为管理者后，发现自己难以面对一些棘手的问题，例如给予员工负面反馈或裁员。作者通过与经理进行沟通以及与他人进行交流，最终克服了这一问题。 作者认为，逃避问题只会让问题更加严重。要勇于面对棘手问题，并积极寻求解决方案。与经理进行沟通可以获得更专业的建议，与他人进行交流可以获得更全面的视角。 作者建议，新晋管理者要勇于面对棘手问题，不要逃避，要积极寻求解决方案，并与他人进行沟通和交流。

😥 **避免拖延维护工作**：作者在成为管理者后，发现自己经常将一些重要的维护工作推迟，例如团队成员的职业发展、技术债务等。作者最终意识到，需要在工作中留出一定的缓冲时间，以便进行这些重要的维护工作。 作者认为，维护工作虽然不像紧急工作那样需要立即处理，但它对于团队的长期发展至关重要。如果过度关注紧急工作而忽视维护工作，最终会导致团队效率下降。 作者建议，新晋管理者要避免拖延维护工作，要为维护工作留出时间，并定期进行维护工作。

🤝 **积极寻求帮助**：作者发现，自己经常会因为害怕被同事误解而避免寻求帮助。作者意识到，主动寻求帮助不仅可以提高工作效率，还可以增进团队合作。 作者认为，寻求帮助并不是一件丢脸的事情。相反，主动寻求帮助能够体现出自身的责任感和团队精神。当遇到困难时，要勇于向同事寻求帮助，并积极与同事进行沟通。 作者建议，新晋管理者要积极寻求帮助，不要害怕被同事误解，要勇于与同事进行沟通，并积极寻求帮助。

Published on July 4, 2024 8:50 PM GMT

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:

I was open with my manager when I was feeling down—sometimes I’d even explicitly ask him for a pep talk. Because he had a higher-level, longer-term perspective and had been a manager for longer, he was often able to point out ways I was having a big impact without noticing.

I asked people for feedback. I found that if I just asked “do you have any feedback for me?” people often wouldn’t, but if I asked more granular questions—“was that meeting useful?”—I would usually learn a lot from it. (See also § angsting.)

I built up other sources of fun and validation. For a long time, my work was the primary thing that helped me feel good about myself. Diversifying that to include more of friends, relationships, hobbies, Twitter likes, etc. smoothed out the ups and downs.

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:

Manage projects according to the owner’s level of task-relevant maturity.¹

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:

Helping people think through their long-term career trajectoryGiving tough feedback or having difficult conversationsPaying down technical debtThinking about where my team needed to be in six monthsGetting an early start on projects with long lead times

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:

Write down everything I have to doSit down with my manager, and together:Roughly rank the list by importancePut a line labeled “Ben can do this much” partway down the listFor everything below the line, delegate it or decide not to do it

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:

You didn’t upset them, they tell you about it, and you can stop stressing.

You did upset them, but they’re understanding about it, and glad that you opened up a conversation. You can apologize and figure out how to do better next time, and they’re happy that the situation seems likely to improve.

You upset them so deeply that they respond by unleashing the incredibly vicious-yet-perceptive tirade that they’ve been stewing on since the incident, reducing you to tears. Congratulations on hiring someone in the bottom ~2% of professionalism? At least your conscience can be clean at this point I guess.

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:

It requires an almost completely different set of skills than the ones you’ve been building so far.

The scope of what you’re responsible for (the health of an entire team) is much broader. You can’t just focus on, say, writing good code—you need to worry about prioritization and planning and hiring and coaching and running meetings and…

Similarly, the set of actions you can take is much broader, so it’s harder to figure out what to focus on.

You’re less likely to get great support and mentorship—most companies are much better at supporting new ICs than new managers.

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

---

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.

Discuss