I've had similar issues in the past, and here's what I did to resolve them: 1. Get the others on board. I assume there are other developers in your team. Pitch

I've had similar issues in the past, and here's what I did to resolve them: 1. Get the others on board. I assume there are other developers in your team. Pitch your ideas to them, and not management, and get whoever is in charge of the developers to agree that your plan is the way to go. If there isn't a lead dev or dev team manager, just get them all to agree on a date where they switch to your way of doing things. 2. Do, rather than ask. I had the same issues with a director that fancied themselves as a coder. To get around this, I implemented a plan, set up a continuous delivery lifecycle, and put it into place. Their FTP access was revoked, and when they went through the (stupid) process to get FTP access again to tweak some CSS the next deployment wiped their changes out. 3. Let them fuck up, and be accountable for their fuck-ups. Ultimately, you can't stop someone in power from abusing it, so when he/she does and it inevitably fucks up, tell them they fucked up and the team will fix it. Going back to my FTPing director, he tried to fuck with some HTML on a Razor template and ended up breaking a page. We had a basic script that checked the sitemap periodically for anything other than 200 responses, and alarm bells soon rang. I asked around on Slack to see who had made live changes without going through the process, and after he (eventually) owned up, we re-deployed the last release and fixed the error. That public log of their fuckup was enough to ensure they stuck to the process after. 4. Own it, but take your time to come up with a solution. I think your biggest mistake is to immediately jump in and start making changes. I know they're a startup, but if I were you I would've committed to a week or two of simply watching and helping the team go about their business as it is. Get everything to tell you what the problems with their current setup is, and lead them towards the answer you want to provide. After that time expires, deliver your findings, backed up with all the feedback you've received from the entire team, and move to step 1. 5. Be prepared to walk if things don't improve. Sometimes, there's only so much you can do. You can have literally everyone on board, except one person in charge, and they'll be more than happy to derail everything in order to do what they want. If you reach a point where you feel that there isn't a way around a blocker, and you're absolutely sure that it's not your (or your teams) fault, then walk. Line up an interview, and simply tell them that you've accepted a job elsewhere. Don't rub their noses in it, or say the obvious reason why you're leaving. The team will probably already know why. Just leave, and thank them for hiring you.