How do I justify time to adopt infrastructure as code to skeptical teammates?

[AndrewJ]

I’ve been trying to get our team to adopt infrastructure as code for new projects, but I keep hitting this weird pushback that it’s just over-engineering for our scale. We’re not huge, but manually setting up servers feels like we’re borrowing trouble. Has anyone else had to justify the initial time investment to skeptical teammates?

[Aaron_W]

Totally hear you. The pushback about infrastructure as code being overkill at a small scale is common. We tried it anyway and the upfront work paid off with fewer firefights and faster new projects once things were wired up.

[Samuel_D]

Thinking in terms of infrastructure as code helps map the cost to risk rather than hours. Manual setup creates drift when a person moves on or a tool updates and that drift bites you later. The upfront time feels big but you gain repeatability and easier audits.

[Adam.J]

Maybe the point is that automation sounds expensive and distant to people who want to ship now I get that but it is sometimes the small slips that bite you later.

[Victoria27]

What if you frame it as a risk management experiment rather than a tool upgrade? If you treat the first pass as a guard rail for changes and a way to prove stability over a couple of releases some skeptics might soften.

[MatthewC]

Start with a small pilot for one project with simple config and a tiny repo If it helps the team see a win you can expand.

[Jerry60]

Some teams respond to a culture change more than a tech shift and infrastructure as code can be part of that shift People read at different speeds and living docs help

[JasonZR]

We tried to keep the bar low and still ended up reframing the goal around faster safe deployments not perfection which left room for doubt and questions