I was hired a little over a month ago by a very specialized (but by no means unique) technology company, which I have consulted for in the past, with common understanding by my new department's leadership that I've come to leverage my experience - consulting dealing with exactly the kinds of dysfunction they have - to help improve things. The C-level who sponsored my hiring keeps telling me that I need to be a "radical element" and shake things up, pushing things to improve, and generally encouraging me to be an independent operator to fix the problems I'm seeing, without giving me any more authority than a senior-level dev would have.
The vast majority of their development staff has been with the company for most of, if not all of, their careers and are very comfortable with the product domain, but incredibly resistant to anything resembling change from an architectural or conceptual standpoint; the department itself is plagued with instances of needless Not-Invented-Here syndrome, the sunk-cost fallacy is deeply endemic to their decision-making process, and at the moment are trying to figure out why their architecture camel-committee can't produce a decision about a component design. While discussions about the architecture itself use terms from modern best-practices, the resulting product and development all looks like stuff from a decade ago that has aged poorly. Every time I bring up that these don't align with what they say they're trying to design/build, I get a lecture from middle management that "this is just how things are done here" and that "this is a very unique environment, and best-practices don't always work here".
Beyond that, they attempted an organization-wide adoption of Agile a couple of years back, which seemed to have gone well for a while, but first decayed into cargo-cult, and now is bordering on being non-existent again. When inquiring with the agile coaching lead (none of the coaching staff are full-time coaches, it's treated as a "floor safety marshal" kind of role) the reason given for all of the changes which have effectively created a scrumfall environment was either "it's more convenient this way" or "the devs are happier with this".
Development is agonizingly slow, amazingly inconsistent (based on velocity charts and cumulative-flow diagrams), and every decision is either rushed to the point of slapdash or drawn out to death.
How can I fill my remit as a "radical element" and drive positive change when it seems like no one wants any real change? I've started down the "win them over" route, but I can't in good conscience not fight back when I'm seeing things that I know are going to lead to a worse product, which hasn't endeared me to anyone.