[brap]

I joined a new team as a manager and after 3 years was kindly asked to step down and become an IC. While there are many external factors to blame, I decided to do an honest postmortem with myself so I thought about these things a lot.

As a line manager a huge mistake you could make (especially if you’re joining a new team) is not being technical enough.

You may not write code anymore, but you are expected to know the system very thoroughly, otherwise you’ll be perceived as a glorified babysitter.

As a new manager it’s very easy to fall into the trap of not doing any technical work because you’re a big boy now playing in the big boy league, but this will 100% hurt you.

You need to stay on top of everything your reports are doing. Give them their space but always ask hard questions and dig deep.

Frame it like this: if this report were to quit today, are you able to step in and complete their project? I’m not saying it’s something a manager is supposed to do, but that ultimately YOU are directly responsible for your reports’ work so you should be extremely familiar with it.

[dowager_dan99]

I've entered 2 new orgs as an engineering manager, after getting some experience organically. You need to prioritize between lots of things, including technical / people. Usually people is the right choice I've concluded, but the first time my teams were using all new tech for me and I really struggled after over focusing on relationships. The second time I still focused more on people but new the tech better, and forced myself to find time to go through more typical developer onboarding. It was way more successful.

Some of the things you mention sound right for a team lead (i.e. single team) but not really for an EM where you might have 2+ teams. You need to be able to solve the problems the leaving teammates create for you, but stepping into the role is probably the last thing you should do. Don't get me wrong, you need to live the life to build credibility and empathy, but doing the job yourself is usually a substandard, unsustainable solution.

[thanksgiving]

> You may not write code anymore, but you are expected to know the system very thoroughly, otherwise you’ll be perceived as a glorified babysitter.

I think the way "experienced" managers do this is to not actually understand the technical work 100% but rather make your manager think you understand it 100%. Even as an individual contributor, I fail to fully understand all the changes my team is making. I can't imagine being 100% fully up to date with all the changes at are in flight, have landed, etc. and why. The best you can do is some kind of abstraction.

They call this "managing up" or something like that.

[majormajor]

For those sorts of things you need to understand:

- the reason it's happening

- the cost (time / people)

- what else you are deciding not to do instead

You don't have to be in the weeds enough to implement it yourself but you need to guard against both:

- people working on things that aren't priorities because they only want to work on their own pet projects, by not being technical enough to tell when they're BSing about the technical justification for certain things

- people doing things in inefficient or not-aligned-with-future-needs ways because they are more junior and don't know some technical things, or because you haven't shared enough roadmap context

It's related to "managing up" in that it's good to be proactive about sharing some of that info upward as-relevant with your boss so that they don't have to go out of their way to know what's going on with you (or else you run the risk of them having a wrong assumption when they're making decisions that impact you and your reports).

[chatmasta]

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.

[ElevenLathe]

Managing up is just rebranded brown-nosing.

[majormajor]

I think it's the direct opposite: A huge part of "managing up" is making your your boss knows what's going on enough to help them make a wrong decision due to being unaware of details you and your reports are aware of. If you're scared of contradicting or correcting them you can't do that.

A huge common mistake for anyone with a boss - at ANY level, IC or management, is assuming their boss knows everything that they know + more things. The intersection of what you know + they know is probably smaller than you think. And so being able to recognize what they will NEED to know in the near future is a valuable skill.

[exitb]

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

I’ve had many managers over the years, more and less successful, and this was possible just for one of them. And only because they were promoted to the position from a developer level on that team. They hated being a manager though and left the company promptly.

[dowager_dan99]

Turning this person into a manager is a major fail. Typically their only move is to quit, and everyone loses.

[resonious]

I'm an IC on a team full of seniors with strong domain knowledge that recently hired in an EM from the outside. In short, it was pretty bumpy and despite the guy being an ex engineer, his constant questions about how the system works were a huge drag. Maybe to him he was digging deep but to me it felt like my (and my teammates') work was blocked by his inability to grasp simple concepts. Like the time spent explaining could've been spent just fixing the bug.

So I guess with the digging deep thing, be careful to not take up too much of people's time!

[diatone]

How long are these Q&A sessions, would you say the work of ICs getting blocked isn’t worth having the manager be able to eg: advocate for that work upwards?

[resonious]

We recently had an hour long session in the middle of the day with the entire team dedicated to explaining to the EM what exactly happened during a recent incident (a fairly sophisticated attack - not a simple bug, to be fair). Then next week another hour long session with the entire team AND a hefty handful of other people where EM regurgitated what we had explained to him. Fine I guess, except I'm pretty sure most people in that "retro" meeting already knew way more about what happened than EM did. So ~40 minutes explaining something to people who did not need an explanation.

[cutemonster]

Sounds annoying. Maybe if he'd asked one person to explain instead of the whole team? How big is the team if I can ask?

> AND a hefty handful of other people where EM regurgitated what we had explained to him.

Is that him trying to show he's doing something useful?

How many people does he manage btw?

[resonious]

The explanation party was maybe 4 or 5 people. The "retro" was 10+ people (almost 20 on calendar but I don't think everyone actually attended).

> Is that him trying to show he's doing something useful?

That is certainly what it looked like to me

> How many people does he manage btw?

About 10.

[cutemonster]

I wonder if, in this case, 10 is too few, and it'd been better with a technical person and manager at the same time? Maybe everyone manages themselves pretty well?

Tech Lead Manager maybe? But I'm guessing. https://www.developing.dev/p/tech-lead-manager-tlm-roles

[dakiol]

What’s wrong with taking “too much” peoples time? I mean, it’s a colleague, asking questions… it’s not that you are going to work more because you’re allocating time to help others.

[cutemonster]

Partly answered here: https://news.ycombinator.com/item?id=42356687

[codingdave]

Having full knowledge of the work is not the same thing as full knowledge of the system. Being able to step in to do the work of one of your people is one possible way to provide a safety net for the bus factor, yes. But not the only way, and I'd argue it is not the best way.

This is your team - you are managing them, not the other way around, so if they have expectations of you that are incorrect, then fix those expectations. If you are not technical, tell them so. Communicate your needs and expectations, and then let them do the work. If there is a bus factor that is too high of a risk for a sustainable team, cross-train the team to remove the bus factor. Have a sense of the priority of all the work so that if someone quits, you can re-arrange the schedule, not be forced to jump in and put out a fire.

At the same time, be building up your people so that they can jump in and replace you. After all, if you cannot be replaced, you cannot be promoted either. Don't pigeon-hole yourself into a front-line manager role unless you truly love it. Grow your team, but grow yourself at the same time.

[alain94040]

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

I don't think that's the main goal for a manager (even technical). I'd say generally, the manager should understand why the team is building something, and the engineers should know how. The why includes who is going to use what was built, when do they need it, what trade-offs can be made, etc.

[dakiol]

IMO, if I have to choose between managers that are technical “enough” and glorified babysitters, I go for the latter. Little knowledge is dangerous and causes more pain than help. At least glorified babysitters know that they don’t know enough and leave all the important tech decisions to the devs; that’s relieving.

[dyauspitr]

That’s the team leads job. The manager’s job is to manage the people. You are a babysitter or more akin to a teacher that has to stay out of the way of the kids doing things well and prevent the bad kids from ruining the class for everyone.

[jiveturkey]

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?