When I first entered an environment with CI and code reviews as a junior, my thoughts were "OMG I am going to get nothing done now - it is going to take forever

When I first entered an environment with CI and code reviews as a junior, my thoughts were "OMG I am going to get nothing done now - it is going to take forever to do anything!". And I was right to a degree - before I could pickup a bug, fix it, and it submit to the main repo without any fuss or review within 5 to 10 minutes and it would be in the next release. Knocking out bugs was a dream - done! fixed! resolved! done! done! done! DONE! project managers loved it as you could just machine-gun through fixes. Afterwards my personal velocity slowed right down and it felt very restraining. This freedom and simplicity to do what is needed for developers is super seductive. If you come in as someone new to a team and want to start taking this away from people, you'll probably get some pushback with people complaining about it slowing them down/taking too long etc So with that said, I don't think your expectations are unreasonable, but if this "wild-west" culture is ingrained it is going to be hard to introduce it. My advice: - get explicit "firepower" from as senior person as you can find. Make the request to do these things come from that senior person, not you. If it is you boss's boss's boss's boss is telling your team to do it, that carries greater weight than "the new guy" (no offense) and complaints about going slow or whatever are then kinda moot since your boss's boss's boss's boss knows the repercussions and wants it done like that regardless. - couch these things as a developer aid. E.g. proper unit testing can help to prevent embarrassing mistakes or make "risky" changes less stressful, CI and repeatable builds means that the boring toil of cutting the release is removed etc. Reviews are a harder sell as most people see it as an intrusion/trust-thing/"we don't trust you not to fuck up without us checking"-thing/etc. - try introducing things piecemeal. At one place I worked, we had CI but failing tests were not a blocker (we had a more of a jokey "hat of shame" where someone had to wear a top-hat or cowboy hat or something if they broke the tests that day) - eventually people ran the tests before submission to avoid the hat of shame and people were proud to say they never had to wear it over the past 5 sprints etc. At another we did "ad hoc" reviews where senior devs or TLs would randomly pick some changes from the other devs and review those after they had been submitted to get some level of oversight - usually hideous hacks, lip-service unit tests, or spaghetti messes were uncovered pretty quickly this way, but didn't "slow everyone down". Slowly as people get used to unit testing and reviews or whatever you can slowly tighten the screws and introduce more rigor. Hopefully eventually people will come to appreciate the benefits these things bring. Good luck.