A thread on r/devops hit 710 upvotes with a familiar story: new engineer inherits a shop where everyone commits to main, there are no pull requests, no CI, no change control, and management thinks suggesting otherwise is a personal attack. The comments split in half. One camp said run. The other said boil the frog slowly. Both are correct, depending on the shop.
If you are the engineer on the receiving end, the standard advice - adopt GitFlow, require two reviewers, wire up a full pipeline - is worse than useless. It is the kind of answer that gets you labeled the difficult new hire and quietly moved off the roadmap. What actually works is a minimum viable stack that looks boring to executives and feels like a mild nuisance to engineers who have been cowboying for a decade.
Why The Textbook Answer Fails
GitFlow, trunk-based development, protected environments with approval gates - these all assume a baseline of engineering culture that does not exist in the shops we are talking about. The senior engineers resisting change control are not confused about what it is. They are resisting because the last three people who tried to impose it either quit, got fired, or gave up. The existing process is a Nash equilibrium. Everyone knows it is bad. Nobody wants to be the person who makes it worse on the way to making it better.
The other problem is surface area. Turn on branch protection, require PRs, add two CI checks, and mandate a code owner review all in week one, and the first outage that follows will be blamed on your changes. It will also probably be caused by them, because nobody knows how any of it works yet.
The Minimum Viable Change-Control Stack
The goal is a setup executives can describe in one sentence - we require a review before code hits production - and that engineers experience as one extra click per commit. Four pieces:
- Branch protection on main. No direct pushes. That is it. No required reviewers, no required checks yet. Just a gate.
- PR required for merge. Default to squash-merge so history stays readable. Allow self-approval at first. Every change now has a URL, a diff, and a comment thread. You are building an audit trail, not enforcing quality.
- One CI check. Pick the cheapest possible thing - a linter, a terraform validate, a shellcheck run. Under 90 seconds, almost never fails. The check exists so the concept of a required check is wired up when you need a real one later.
- Read-only deploy credentials where possible. If deploys use an IAM role, scope it down. If they use a long-lived token with admin on everything, that is the actual crisis. Change control on code means nothing if any laptop can push to prod.
That is the whole stack. Ugly. Incomplete. Also 80 percent of the risk reduction at 10 percent of the political cost.
The 90-Day Rollout
Sequence matters more than the controls themselves:
- Days 1-30: Instrument, do not change. Turn on audit logging. Document the current deploy path. Find out who has prod credentials and what scopes they have. Write it down and send it to your manager. You are not proposing anything - just making the current state visible. This is the step most engineers skip, and it is what gives you political cover for everything that follows.
- Days 31-60: Branch protection and PR-required on one repo. Pick the least-contentious one - internal tooling, infra scripts. Self-approval allowed. No required checks. Let people get used to the workflow on a low-stakes repo before you touch anything that ships to customers.
- Days 61-75: Add the one cheap CI check. Same repo. Make sure it almost never fails. When it does, help people fix it personally. Do not lecture. Your job this month is to make the check feel like a helpful coworker, not a bureaucrat.
- Days 76-90: Expand to two more repos and tighten deploy credentials. By now the workflow is normal. Adding it to more repos is paperwork. At the same time, quietly replace any long-lived admin tokens with scoped-down credentials. Do not announce it. Just do it.
Notice what is not in this plan: required reviewers, protected production branches, signed commits, mandatory code owners, SBOM generation, SLSA attestations. All good things. None belong in the first 90 days. They belong in month six, after you have earned the right to propose them by not breaking anything in the first three.
When to leave: when leadership has been told in writing that the current setup carries regulatory or contractual risk, and the response is to ask you to stop bringing it up. That is not a culture problem. That is liability with your name on it. Start interviewing.