How to Convince Your Team to Adopt Infrastructure as Code

Convincing a team to adopt Infrastructure as Code is not a technical challenge - it is a people and process challenge.

Day 19 of my Terraform journey focused on this exact question:

How do you actually convince a team (and leadership) to adopt IaC?

Here is what worked for me and what I’ve seen in real team workflows, grounded in Chapter 10 of Terraform: Up & Running by Yevgeniy Brikman.

1. Start With the Business Case, Not the Tool

The biggest mistake is leading with Terraform features.

What leadership really cares about:

• fewer incidents
• less downtime
• predictable releases
• auditability

In the teams I’ve worked with, the real pain points are:

• manual changes after PR merges
• environment updates applied directly on servers
• outages caused by exhausted workers
• secrets stored on servers and readable by anyone with access

So the argument is not “Terraform is cool.”

The argument is:

• “We can reduce production incidents caused by manual drift.”
• “We can standardize autoscaling and reduce downtime.”
• “We can build a full audit trail for infra changes.”

This aligns with Brikman’s key point: lead with the problem you are solving, not the tooling.

2. Adopt Incrementally, Not All at Once

Big‑bang migrations almost always fail.

The safer strategy is incremental:

• pick one small, real problem
• solve it with IaC
• show results quickly
• build trust and momentum

A simple first win would be:

• a new S3 bucket managed entirely in Terraform
• remote state stored in S3
• PR workflow for infra changes

This reflects Brikman’s lesson: incremental wins build momentum and reduce risk.

3. Give the Team Time and Safety to Learn

IaC fails when only one person knows how it works.

In a real incident, people will choose the fastest fix.

If Terraform feels slow or unfamiliar, they will go manual - and drift begins.

To avoid that:

• training time must be deliberate
• workflows must be documented
• the “right way” must be the easiest way
• PR reviews and terraform plan should be standard
• no manual console changes for Terraform‑managed resources

This is the cultural shift Brikman emphasizes: code‑first operations must be taught and supported, not assumed.

4. Common Failure Modes to Avoid

These are the patterns that keep showing up:

• Trying to migrate everything at once
• Starting without leadership buy‑in
• Underestimating the learning curve
• One person owns all IaC knowledge
• Outage happens and the team goes manual
• Drift accumulates until Terraform is abandoned

The fix is always the same:

• smaller steps
• clearer training
• consistent team practices

A 4‑Phase Adoption Plan That Works

Phase 1 - Start with something new (2–4 weeks)

Create a new S3 bucket (logs/backups) in Terraform.

Low risk, clear win.

Phase 2 - Import existing infrastructure

Use terraform import for one high‑change resource (e.g., security group).

Phase 3 - Establish team practices

Module versioning, PR reviews, terraform plan in PRs, CI checks.

Phase 4 - Automate deployments

CI/CD runs terraform apply on merge to main with approval gates.

Each phase delivers value even if the next phase takes longer.

Final Thought

If you want your team to adopt IaC, don’t start with the tool.

Start with the biggest pain the team is already feeling.

Solve that one problem with IaC.

Then repeat.

That is how real adoption starts.

GitHub (Day 19):

👉 Github Link

Follow My Journey

This is Day 19 of my 30‑Day Terraform Challenge.

See you on Day 20.