But...the other 4 times I get either no solution, or the Upload button only works as long as one user at a time tries it, or only on Chrome when all customers use IE8, or the documents randomly disappear when new dockers spin up, or the button needed to be WCAG compliant and no one bothered checking, etc. Suddenly I am forced to be Manager B and no one is happy. The feature is 3x over budget and 3 weeks late.
What leading indicators can we use to predict or at least alert to a failing Manager A project early in the cycle so I can do what I love, devs can do what they love, biz stakeholders get things on time and on budget, and customers can get something they love?
Whatever's going on, you gotta catch it sooner, right? Any way the stories can be smaller and get out to QA sooner?
Maybe you could try being "Manager AB"
Instead of a totally hands-off "Manager A" style maybe you can work more closely with them to develop those stories and make sure they understand what technical requirements (WCAG compliance, etc) each story needs to hit before they estimate them
But experts are fallible, and distractions are many, and sometimes even experts get lazy or confused or overwhelmed.
I was at a company that did Scrum. There were two managers who functioned as product owners on the scrum teams.
Manager A took the correct approach. Developers were aware of the overall goal, and we broke those goals down into stories, and broke the stories down into tasks. As developers we had a good sense of ownership and responsibility.
Manager B tended to just issue stories (which were really mini specs) to us. We were treated like children. We didn't know why we were doing what we were doing, and were not able to contribute to the design of the solutions we were handed, which were often suboptimal.
A lot of teams take "Manager B's" approach and wonder why the developers hate Scrum.