> I realize there's a lot of "hate" towards non-technical it-project managers
That's probably not true. There's certainly some "hate" towards pointy-haired managers in technical projects which don't care about the technical view on the project. I've both been a project manager (with a technical background) and have had project managers without that background. Whether you're the "used to be a software engineer", "mechanical engineer" or "gender studies" type hardly matters, though, for the software engineer.
The projects with the biggest problems were generally those, where the project manager was disinterested in the technical aspects or didn't have the capacity to grasp basic concepts, in particular regarding interfaces and architecture. (I remember one particularly annoying project manager who sighed audibly in meetings that were specifically there to discuss interface details, if interfaces were discussed. Of course, she ended up not even understanding the top-level interface of the project she managed and thus we lost weeks during integration.)
So, if you feel like you're just taking notes and you can't contribute, I have one important point: Involve the other engineers. Ask questions if you're unsure. If you're insecure, believe me, they will in all likelihood already have sized you up and know your level of knowledge. There's nothing you can do to embarrass yourself and if you want to work as a team, it's important that they know what you know.
> Right now, I'm focussing on "shielding" my devs from managers/clients, by translating the business-needs of the clients to somewhat accessible backlog items (stories, features etc.) that I simply ask my team to complete with proper descriptions, estimates etc.
Engineers may or may not want that, depends on the details. In particular in agile-ish environments that shielding is considered not helpful. If the requirements are well-known and well-established beforehand, though, make sure that your translation does not introduce further confusion. (Typically, at least in formal projects, this is often done by establishing tracking between initial requirements and your specifications. Thus, your engineers can work on your interpretation and consult the initial requirements as well.) Shielding feedback is necessary if the feedback is obviously not helpful, unproductive or not in line with the project goals.
> given the fact that I'm in charge of progress and business outcomes?
This may be the most important point here, as this is (probably) your task: Track the state of the project, its progress, its impediments and keep the project in line and every stakeholder, including the engineers, informed.
You also need to understand the progress, as it can be tricky. A not well-understood progress may indicate 90 % completion, whereas you still need the same time you already needed to get it to 100 %. To understand whether this is the case, you need to be able to ask the right questions. I.e. if something an engineer tells you seems fishy, ask about it. If they have concerns, ask about them. Good engineers generally don't mind questions, so involve them to that degree in your job.
However, these points aside, there are a lot of other things that make people good project managers for engineers. For example, if you're in a high-conflict team you may need to help resolve conflicts. If you're in a slow team, you may need to push for a faster pace. If your engineers produce low-quality output you may need to tweak your requirements for more testing and accept that the estimations will go up.