Mistakes as a new manager

> For over a decade, my dopamine (from work) came from a very predictable place: shipping new things. As a manager, those direct rewards will simply disappear, leaving you feeling unfulfilled for weeks (months in my case).

Your job as a manager is still to ship things -- only now it's to ship more than you ever could alone. You get the privilege and responsibility to steward the skills of two or more engineers and shape the entire part of a business. The dopamine is harder won and often more rewarding. Management is difficult and exhausting but it's anything but unfulfilling. Let's not start new managers off telling them what they can't do but what they can do.

Ironically, as a manager of software engineers you should still be very engaged with the team's code. How else will you understand your capacity and understand what gaps you need to fill? Run the test suite, review designs, read PRs, ask questions, give praise for attention to detail. You will keep the bar high on the team and advocate for their work more effectively within the organization.

I’m surprised by this and curious at the “team thinks” framing. What advantages do you see here?

I think I would much rather own the critique myself than say “the team thinks x.”

For context, I’d probably start with “what happened with that deployment that was rolled back?” and let them self-diagnose and share their perspective. By listening, I might learn there were extenuating issues, or I may see they are already aware of the issue.

If they’re able to critique their own work, I can agree and reinforce the whys. There’s no hostility and we can talk about what ideas we have for what we can do going forward.

If not, and I think we must do better, I can talk about my concerns, my expectations, and the consequences that I am worried about or frustrated by, and propose more prescriptive remedies.

It implies the persons' leverage is limited to only what they personally do. That's obviously false. A non-manager engineer can have broad scope in putting in a proper architecture, in mentoring others, in cross-team communications. I would go as far as saying there's virtually no engineer whose impact is limited to themselves. They have a harder job since they need to affect change without having official authority to affect change.

The term's very existence it puts people in a certain bin. Why is a CEO not also an "individual contributor"? They're an individual. They contribute. It's just newspeak.

I've never thought of management positions in an organization to reflect something derogatory. But maybe to some.

Maybe it means the manager assigned work to someone junior that was beyond their capabilities? I suggest the manager has a talk with themselves along these lines: "I've noticed you've assigned Jimmy to work on improving the scalability of the widget producer. In retrospect this was beyond where Jimmy is right now in his journey as a software engineer. Let's reflect on this incident and try to make sure that we have people working on things that help them grow but don't put them in a position where they don't have the experience to do the job right and also to realize they don't have that experience".

Seriously though, I don't think there's "healthy conflict". There are healthy relationships where you can someone they're full of it without it being an insult or you can discuss how to write better software without it being perceived as a personal insult. An environment where people want to grow, are curious, are friendly, and just talk about how to do things better. Once you're in "conflict" territory it's something else. Unfortunately in most organizations you actually do have to get into conflict territory to impact change but I don't see that as a positive thing, just a negative that is a fact of life.

EDIT: This "I noticed blah" pattern is what's taught in formal management training as a method of giving feedback. I know because I've done those. The problem is that wrapping negative feedback in some formulaic pattern is transparent and doesn't work. So the person receiving this immediately strips away your formula and hears the negative feedback. I know that's what I do when someone uses those tools on me. The way forward is not to use those tools but to engage in a true positive way and foster a positive atmosphere. A smart person already knows there's a problem when their code got rolled back. The discussion shouldn't be about their performance "issue" but just about assigning people jobs they can handle and giving them tools and support to that right. There are exceptions when there are more complicated things going on, but the way this is handled when people have good intentions and are motivated is to generally keep helping them stay motivated and have good intentions even when they make mistakes.