Mistakes as a new manager

I build internal tools, do BS support requests and push little initiatives that align with my core values. Like get a dozen people in-person for a technical watch party - cheap, easy, super rewarding.

for these IC/leaders a big mistake is taking on critical path work, then blocking everyone else.

I’m pretty sure “managing up” refers to the extra work the IC needs to do so that their non-technical manager doesn’t look incompetent to their own manager.

I agree with the sentiment and importance of addressing these things, or dealing with conflicts in-general, but I disagree with the tone somewhat and disagree with the notion that you're not in the trenches with them, but it depends on what trenches means to whoever it's relevant to. I feel like many new managers know they'll need to deal with this, but never developed their abilities prior to being a manager, and don't realize that just because the conversation happens, doesn't mean it produces valuable outcomes, breeds respect, or means anyone will like the way you approached it, or even that you were as vulnerable or honest as you thought you were.

Every manager I've had that used your example quote—almost verbatim—went on to be incredibly passive-aggressive, because they're trying too hard not to actually create conflict, they want to be liked more than they care about the result, they don't have that much innate confidence, or like the author of the article suggested, they want to see the results they would have produced when they were an IC, and haven't yet learned how to guide autonomy and relinquish a certain amount of control. These are perhaps the traits that led them to keeping their IC job all those years.

These people would turn 1-on-1s into 45 mins of beating around the bush, trying to get me to reveal myself as having insufficiently met the unspoken criteria they've been having internal anxiety attacks about, and maybe in the last few minutes when there's no room left for pushback they'd conjure the answer they wanted to hear and set that as the benchmark.

This failure on their part predictibly bled into other interactions and created toxicity and resentment, they couldn't yield control, and they couldn't have a real discussion that involved more than themselves manifesting as their overbearing mother waiting for their kid to implicate themselves for some petty wrongdoing. They couldn't clearly communicate priorities, or timelines, or requirements, and were starting in their new job with a skill issue of their own. They hadn't adapted to the role or developed a good personality for it, and apparently lacked an ability to reflect on their behavior or communication style.

I don't mean to extrapolate too far from this or in-turn attack you in any way, it's just a small quote, but in the past it's been telling.

"Can we talk about code quality issues" doesn't just avoid a character trait, which I agree should should never be the target, it leans into vague, soft, meek, intentionally indirect language that just creates undue anxiety and establishes an ambiguous context for whatever the problem might be, and was a dishonest pretext for for downstream attribution of fault, since they couldn't accept the possibility that the problem might be upstream (which it wasn't always, but if it had been, they weren't going to address it then). In these situations, sometimes I was struggling with purely my own productivity, having a bad couple weeks, but otherwise it was some other issue they weren't willing or able to genuinely help me with.

Do your best to be humble, learn to delegate and try to trust people, avoid thinking about character traits but don't avoid direct (and clear) language, and accept that your perception might be inaccurate. Get as far away as necessary from the dreaded "just checking in" or "is there anything we can do to improve (your problem)" as possible. What if their code is suffering because of noise in the office or someone's depressed because they're having relationship issues? What if it's because you keep coming over to their desk unannounced and asking diverting their attention?

If you can do that, you're on a good track.

Edit: it's worth noting that the underlying assumption in all of my comment is that people and their reasons and issues are often different, and likewise how they respond to this language may be different, and as such many might actually love the quoted phrases because they aren't imposing, and a good manager will do their best to communicate with people in a way that accepts that a variety of ways to address conflict is the right move, and sometimes less imposing language is viable.

Not at all. I mean for a small team where you are or expected to perform as TLM yes. But generally speaking no.

I can't read the article to tell if this is just an observation from you, or if you are responding to the article, because my DNS just broke for whatever reason.

> Frame it like this: if this report were to quit today, are you able to step in and complete their project?

That is not the manager's job. The real question here is, do you know the bus factor of your team and do you know what particular skills are most critical to replace?