Mukami

Posted on Apr 12

How to Convince Your Team to Adopt Infrastructure as Code

#aws #terraform #30daychallenge #iac

The Technical Part Is Easy. The People Part Is Hard.

Day 19 of the 30-Day Terraform Challenge — and today I learned something uncomfortable.

The technical part of Terraform is the easy part. Writing configurations, managing state, setting up modules — that's straightforward compared to what's actually hard:

Getting a team to change how they work.

The Problem: Engineers Don't Resist Technology

Engineers don't resist technology. They resist:

Changing habits they've had for years
Learning new tools when the old ones "work"
Slowing down to do things the "right" way
Trusting automation over their own judgment

If you're trying to introduce IaC to a team, you're not solving a technical problem. You're solving a people problem.

The Business Case (What Leadership Cares About)

Leadership doesn't care about "better infrastructure." They care about outcomes.

Business Problem	IaC Solution	Measurable Outcome
Infrastructure incidents from manual errors	Code review catches mistakes before apply	Fewer production outages
Hours spent on repetitive environment setup	Reusable modules provision in minutes	Engineering time freed for product work
No audit trail for compliance	Every change is a git commit with author and timestamp	Full audit trail for auditors
Dev environments differ from production	Same config for all environments	Fewer "works on my machine" incidents
Slow onboarding for new engineers	Documented, version-controlled configs	Faster onboarding time

Frame the conversation around outcomes they already care about.

Why Most IaC Adoptions Fail

According to the author, the most common reason IaC adoption fails is:

Trying to do too much at once.

Teams attempt to migrate all their existing infrastructure to Terraform in one big project. It takes months. People get frustrated. Things break. Management loses confidence. The project dies.

The fix: Start small. Win early. Build momentum.

The Incremental Adoption Strategy

Phase 1: Start with Something New (2-4 weeks)

Do not migrate existing infrastructure first. Pick one new piece of infrastructure — a new S3 bucket, a new IAM role, a monitoring dashboard — and provision it entirely with Terraform.

Why this works:

Zero migration risk (it's new, not replacing anything)
Quick win (days, not months)
Team learns without pressure
Creates a success story

Success criteria:

Configuration is code-reviewed and merged
Remote state is configured in S3
Team members can run terraform plan and understand the output

Phase 2: Import Existing Infrastructure (4-6 weeks)

Once the team is comfortable with the workflow, begin importing critical existing resources.

# Example: import an existing S3 bucket
terraform import aws_s3_bucket.existing_logs my-existing-logs-bucket

# Example: import an existing security group
terraform import aws_security_group.existing sg-0abc123def456789

Prioritise resources that:

Change frequently
Have caused incidents
Are well-understood

Do not try to import everything at once.

Phase 3: Establish Team Practices (Ongoing)

Once multiple engineers are writing Terraform, establish the practices that prevent chaos:

Module versioning
Code review requirements for all infrastructure changes
terraform plan output as a required part of every PR
Automated terraform validate and terraform fmt in CI
State locking enforced via DynamoDB
No manual console changes to Terraform-managed resources — ever

Phase 4: Automate Deployments (6-8 weeks)

Connect Terraform to your CI/CD pipeline so that merges to main trigger terraform apply automatically.

At this stage, infrastructure changes go through the same review and deployment process as application code.

The Cultural Shift

Technical changes require cultural changes. Here's what needs to shift:

From	To
"It works on my machine"	"It works in the code"
Manual console changes	Pull requests for everything
Blaming the tool	Blaming the process
Heroic fixes	Reliable rollbacks
"I know what changed"	"The git log knows"

Building Trust in Automation

Teams don't trust automation because they've been burned before. Build trust through:

1. Visibility
terraform plan output is the most transparent change preview possible. Use it in every PR.

2. Safety
Start with read-only changes. Let the team run terraform plan for weeks before anyone runs apply.

3. Rollback capability
Show the team how to revert a change in minutes. Trust comes from knowing you can recover.

4. Gradual rollout
Start with low-risk resources. Work up to critical infrastructure.

What I've Observed

In my experience, the hardest part of IaC adoption isn't technical. It's getting experienced engineers to trust code over console.

Engineers who have been burned by bad automation resist. Engineers who have fixed things manually for years don't see the problem.

The solution isn't better tooling. It's small wins that build confidence over time.

The Bottom Line

The technical part of Terraform is straightforward. The real challenge is:

Convincing leadership to invest in IaC
Getting engineers to change their workflow
Building trust in automation
Moving incrementally when everyone wants to move fast

Start small. Win early. Build momentum. The rest follows.

P.S. The next time someone says "we should just do it manually this once," you'll know that's how drift starts. One manual change becomes ten. Ten becomes a hundred. The only way to win is to never start.

DEV Community