They leans on us 100% for technical information.
I would hate they not being there as the information flow would be very bad without and priorizing stuff would eat up other half hours of the day.
We're lucky that they don't have a micromanagement tendency, which means that when they say not to work on something it's usually backed up with a valid reason.
If the manager is changing sprint scope in scrums/daily stand-ups then they're being naughty. If they're policing order of execution, then maybe it's ok, but they should do that at planning time.
Managing timeline failures, particularly externally, and motivating other teams to unblock you is a primary management function.
Managers going to stand up doesn't seem like an anti-pattern to me.
And the PM loves to jump in to dev conversations that he doesn't understand on Teams too.
1. Needs more than one programmer
2. The domain of the program is not the expertise of the programmers
Then you need someone to talk with the domain experts. Ideally someone who can communicate well, get information and handle the upcoming problems which arises whenever different domain expertises meet.
This role is called a manager, sometimes product manager. Sometimes the application is so large one person is not enough. Sometime a corporation is so disfunctional there are more managers talking than programmers doing the actual work.
But in its essence it is not a useful but an essential part of building something for other people.
Look at this field manual for some inspiration:
https://www.openculture.com/2022/01/read-the-cias-simple-sab...