[alanfranz]

> However what they all did have in common was that they knew their limitations and always deferred to the relevant experts when faced with technical decisions that they didn't have insight into. You need a lot of skills to be a good manager

Can I ask you (sincere question, I'm investigating the topic) what kind of value did your manager provide if he had zero ideas about how your job was done?

I mean: if he trusts you, and does what you ask, that's great. But I'd find very difficult to manage a team without understand their jobs. How can I help them in their job, and help them improve? What's my role?

[torben-friis]

>I mean: if he trusts you, and does what you ask, that's great. But I'd find very difficult to manage a team without understand their jobs. How can I help them in their job, and help them improve? What's my role?

For the managers I’ve had that work that way, the work is basically human shield.

Meetings with stakeholders, random corporate demands, bugs that people attempt to escalate more than they should because someone in the chain is particularly vocal… their job is to deal with that so programmers don’t have to.

Additionally, acting as coaches (improving team relations, solving friction between colleagues, etc) and acting as an artist’s representative for their programmers, playing the necessary work politics so that they get their raises and promotions.

[denton-scratch]

One of my earliest line managers was a programmer. I don't think he was a particularly good one, but he was a good manager. He was a good-enough programmer to understand my job, anyway.

What made him a good manager was that he removed obstacles for me. He made sure I had the equipment I needed; he dealt with bureaucracy problems; and he hooked me in to experts when I needed advice. He was great. we got on well, and I was his right-hand man.

Then he got promoted, moved to Head Office, left me behind, and I never spoke to him again. He was replaced by a dullard checkbox manager, and I moved on within a couple of months.

[Multicomp]

Not GP. But for me, even a non technical manager has a full plate of duties.

1. Shields up, Scotty. Random drive by requests, intracompany resource raiders, time sucks for random asks, even just garden variety legwork to clarify (in the GTD sense) next actions on a company project all serve to keep the flow of programming moving

2. If I and a dev on my team disagree and can't resolve if ourselves, we need a judge to present our cases to and have an executive decision made

3. Our team culture and API are implicit contracts that everyone is stuck with no matter what, but if the manager encodes known processes and standards for how we work and principles the team assumes, everyone both on and off the team can benefit from the reduced friction and frustration they encounter when trying to work with the team (or in the team) because they are no longer trying to row against the current or "hold it wrong"

4. Even if all the available work is well defined and well specified, there won't be enough resources to do all the work at once. Even if you trust the devs enough to know and pick the higher priority work, communicating that out to external parties and ensuring that everyone involved has proper expectations is an important task that devs are just not invited to the right manager status meetings for etc.

5. If you see a dev spinning their wheels or getting stuck in the process, take a note of what you observed and stash it away until the next 1x1 with them or potentially see if 2 or 3 similar situations come up, then bring up the observations and work with the dev to see id they can improve their processes or if the business function has flexibility too

[quintushoratius]

IME (I'm not the person you replied to) a good manager does a few things:

- understands the business requirements for the project(s) you're working on;

- helps coordinate the non-technical parts of projects, e.g. facilitator, finding overlaps, and (when they occasionally arise) dispute resolution;

- works on road blocks to getting your job done.

None of those require in-depth technical knowledge.

A good manager may have opinions about the minutiae of what you're doing, but keeps those opinions to herself. After all, the manager's purpose is to leverage their reporting ICs into getting more done, not doing the task herself.

[skeeter2020]

This is a good question, and I largely agree. I think the answer to your final question is in the preceeding two: a manager should be continually asking them (a) for the team and (b) for each individual on the team. Then next ask "what actions am I taking right now to test/implement these answers?".

A good manager doesn't need to know your job (that invites micromanagement) but they do need to known the "interface" for your role and be willing & able to learn aspects as they relate to growth and improvement. Managers work on a 2nd-order system that's an abstraction of the software you're building but with added complexity because it involves people. Depending on the balance it can look very similar or very different from the one developers navigate.

[voidsnax]

I think a big part of an engineering manager’s job is protecting their team’s focus, and advocating for their team to the rest of the organization. Programmers should be insulated by an engineering manager from the vicissitudes and stresses of corporate politics, and their work should be protected from management-level priority thrashing.