> There's another angle as well at play... My command chain cares about delivery of services and products at our below the budget, period. This is classic dupl

> There's another angle as well at play... My command chain cares about delivery of services and products at our below the budget, period. This is classic duplicitous manager babble that really just means, "I want authority to decide arbitrarily when we should adhere to bureaucratic rules or project management methodology (... or good coding practices, or sane deadlines, or ...)." When people actually care about the business bottom line (what you describe as delivery of services and products at [or] below the budget), they tend to behave rationally and expand their point of view to include things like bureaucratic necessity, the importance of strictly adhering to chosen project management and code quality standards and never cherry picking which business concerns are supposed to override them, and so forth. When people up the command chain don't behave rationally about this stuff, it's generally because they are bad at their jobs. Bad managers see subordinates as work receptacles who should "just get shit done" and "solve my problems" without any understanding as to how it works or what constraints from reality actually mean in terms of unpackaging business priorities and mapping them to actions to accomplish them. As a manager caught in the middle, you can chose which way you want to go. Appease the batshit bureaucrats by hammering down on your own subordinates, bottomlessly compromising away standards all in the name of so-called business bottom line. Or stand up to them and explain what it takes to actually deliver products. If you lose your job doing this, it's a good thing! It allows you to rejection sample bad employers and more quickly find good employers where the managers realize that the phrase "business priorities" has to be recursively unpacked into all the messy details of project management, budgets, deadlines, work/life balance, and so on, and who actually care to do so (and yes, they really, really exist, just not embedded in brainfucked corporate/organizational hierarchies). One example from my own career: I worked on a team of developers for an education technology company. The company acquired a start-up that had created a suite of learning applications. The code was an unbelievable mess: written in a (bad) proprietary language, poor anti-patterns all over, no usage of proper version control or issue tracking, no sane build or deployment system. To boot, the apps themselves consistently got poor reviews from users in all of the app stores and review sites. And instead of fixing the app and improving the project management methods (truly the only two options for even short term profitability of the app), the management decided to essentially throw gas on the fire and pursue a strategy similar to regulatory capture, and attempt to make the creation phase of the learning materials (things only professors, teachers, or administrators would do) into the first-class constructs of the whole system, further crapifying the experience and functionality for end users (students) and driving app engagement and reviews even lower. After a while of this utterly not working, there were several heart to heart meetings between engineers, middle management, and senior management, at which point it came to light that one of the main reasons we were even pursuing this strategy at all is that there was somewhat of a dick-measuring competition going on between the company's CTO (who was in charge of this portfolio of products), and the CEO of the start-up that had been acquired. Apparently the folks in that start-up, once their golden handcuffs contracts ended, basically took most of the same e-learning idea and tried to spin it to sell it for corporate learning (like corporate training videos and stuff). And our CTO, who was under pressure about the whole deal and our continued poor app ratings, took it personally and basically started enforcing business strategy solely to "stick it" to that startup CEO and compete directly with him for a new market (corporate learning) that we weren't set up to service and had no prior ties into and had no infrastructure to deal with. And of course, every middle manager in between was feeding all of us engineers the same line of bull as from your comment. Everything was just "upper management cares about most efficient delivery of our product" -- when it was patently obvious that they did not at all care about this and that we were being reprioritized constantly to service the arbitrary whim of the CTO. And because this was a huge organization with tens of thousands of employees, consistently losing tens of millions of dollars on a monthly basis to competitor apps who actually took software quality seriously didn't even register as a blip to worry about. If our whole team got laid off because this CTO's strategy of irrational pissing contest competition didn't pan out, who cares? We'll just slap some crap on the front about how the market is changing or we need to streamline or restructure or whatever. My main takeaway was basically that any time a middle manager tells you a decision is being made because it is important for the efficiency of reaching the company's bottom line goals, that manager is just spewing bullshit. When that stuff really happens, non-bullshit-spewers will actually sit down with you and explain it, in nitty gritty detail, and will actually listen to and value your input about whether it's a good idea or not. They won't rush to label you as a "batshit bureaucrat" or a "religious adherent" of quality practices. They'll just listen and be open and transparent.