There's just so much evidence that extensive meetings are a detriment to software developers. Despite that, companies still hire developers, pay them a lot of money, then prevent them from actually doing quality work with constant meetings and interruptions. I don't get it. If you're a dev manager, you should be doing everything you can to protect your team from wasteful and pointless meetings. Any meeting, particularly standing ones, should require a very strong justification for its existence, because the impact on developer productivity is huge.
At my current job (and most previous ones), the default answer for any organizational problem seems to be "we'll just schedule another meeting" or "we'll open a new Slack channel, and invite everyone to it".
It's also not a good idea that all of your time is related to a codebase or two (i.e. don't put all your professional eggs in one basket). Imagine if those projects go poof or something critical happens. When you're 100% invested you're seen as 100% responsible when the baby management blame game comes. Give me some meetings, give me some non-software soft tasks. If all you do all the time ever is code, good luck changing careers should you ever want to, you're going to have limited other experience.
Also, if your entire job is mopping floors and the floor is dirty, you're going to get shit for any and all dirt on the floor, regardless of how reasonable the expectation is that you could have gotten to the specific mess observed at the specific time. Youre 100% on floors so why didn't you fix this unreasonable request. Meanwhile, if you clean floors half the time and clean windows the other half of the time, you have a valid excuse as to why the floors aren't perfect, at least in some peoples skewed perspectives of expectations. This is why I always advise people have a little split up of their time but not an extreme amount. It gives a clear out to unreasonable expectations. If you wanted the floors so clean I wouldn't do windows half the time, and so on (just be careful not to convince someone it would be a good idea to commit you 100% to a task).
If the alternative is that you're excluding them from all decision making and planning, then yeah, they're going to feel like code monkeys, and that sucks. There's a middle ground between "we have lots of meetings where all planning and decisions are made, and everyone has to be present" and "our devs don't come to any planning meetings, and we just throw all the work to them when the decisions are made".
A good first step is having more asynchronous discussions.
I think you have to delegate ownership down; "you have total control over everything and we won't second guess your decisions." This doesn't happen, so we just have meetings with the "owners" to try and convince them to do our thing. The result is less stuff getting done.
At my current job (and most previous ones), the default answer for any organizational problem seems to be "we'll just schedule another meeting" or "we'll open a new Slack channel, and invite everyone to it".