[dagw]

this should be blatently obvious.

Maybe I've just been lucky, but in my 15ish years of working I've found the correlation between "good programmer" and "good manager" to be zero or possibly even negative. Most of the best managers I've had either never could've done my job or hadn't programmed since Lisp went out of fashion. 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, being able to make good technical decisions is one you can easily delegate.

[tanepiper]

I don't disagree from my experience over 20 years, but I also guess than now I am a manager/leader - I'd hope this isn't the case for everyone?

The biggest thing I've learned is empathy and communication is key - tech doesn't matter in the end, but you have to be able to spot and stop bullshit.

I'm leading people across two major projects at a worldwide retailer - one being a new project driven by my tech decisions and architecture - and I'm also responsible for the welfare and upskilling of the teams.

The sacrifice is not doing day-to-day coding or even code reviews, but taking on more strategic decisions, and working more at the architectural level and handling all the stuff like stakeholder management, getting BIAs and Architecture reviews done, etc. That way the team can focus on what they need to do and not worry about management bullshit.

[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.

[usrusr]

"they knew their limitations"

That's the key here. And it's really a coin toss whether previous programming experience makes a manager more aware of limitations or completely oblivious. Perhaps most likely both at once, acutely aware of being disconnected from the state of the art (or even from the state of the art within the org, even if that's also far behind) yet completely underestimating the actual amount.