*Your team shouldn't be the emotional support group for your architecture.*
There's a very specific kind of fear that enters a small engineering team when someone says:
"Don't worry, Terraform manages it."
At first it feels comforting. Infrastructure as code. Reusable modules. Enterprise workflows. Clean architecture diagrams. Everything versioned. Everything declarative. Everything "scalable."
Then six months later someone needs to rotate a secret and suddenly three engineers are staring at a failed Terraform plan like archaeologists trying to decode an ancient warning tablet.
I don't say that to knock Terraform. Terraform is powerful. In the right environment, with the right staffing and operational maturity, it solves real problems elegantly.
But small teams have a dangerous habit of inheriting infrastructure patterns designed for organizations with:
- dedicated platform divisions
- infra specialists
- module governance
- architecture review boards
- and at least one engineer whose entire personality is Terraform state management
We did not have that team.
What I inherited was a small group of engineers who mostly just wanted to support services and ship code safely to production. Before I joined, some deployments were literally happening from engineers' laptops directly into production through Cloud Run jobs. That was the mentality. Keep the services alive. Move fast. Support the business.
Then suddenly those same engineers were expected to operate inside a heavily managed Terraform Enterprise ecosystem layered across Kubernetes, networking modules, secrets management, CI systems, state files, and deployment workflows.
On paper it looked mature.
In reality it felt like introducing a second job.
## Simple things became emotionally expensive
- Rotate a secret? Open Terraform.
- Need cluster configuration? Open Terraform.
- Need environment changes? Open Terraform.
And god forbid a staff engineer did a POC six months ago, left some drift behind in state, and now your networking module suddenly wants:
- 7 changes
- 5 additions
- resources nobody on your current team has ever touched
- and a plan output long enough to qualify as weekend reading
Nothing builds confidence before a production deploy quite like: *"Why is Terraform trying to recreate networking resources I didn't even know existed?"*
## The real issue: complexity ownership
At some point I realized the issue wasn't Terraform itself.
The issue was **complexity ownership**.
We had inherited infrastructure patterns designed for teams with dedicated platform bandwidth, but the actual team just needed:
- safe deployments
- understandable workflows
- reliable secret management
- and confidence that deploying an app wouldn't accidentally awaken ancient networking demons
Infrastructure had become "correct" architecturally but exhausting operationally.
## So we changed direction
We moved workloads onto a managed Kubernetes platform and simplified the ownership model dramatically. Instead of routing every operational concern through Terraform workflows, we focused on standardizing application delivery and reducing the amount of infrastructure engineers needed to think about daily.
We centralized secrets into a native secrets management tool instead of threading secrets through multiple Terraform abstractions and deployment layers.
CI/CD became:
- build
- test
- scan
- deploy
Not:
- open four repos
- investigate state drift
- update variables
- re-run plans
- emotionally recover
- then finally deploy the actual application
I also built reusable repository templates with parameterized Kubernetes configs and standardized deployment patterns so onboarding new applications became significantly easier. Developers didn't need deep Kubernetes or Terraform knowledge just to ship code anymore.
And honestly, that changed the team dynamic more than the technology itself.
Non-infrastructure engineers could participate in deployments confidently. Operational workflows became understandable. Secrets became manageable. Shipping stopped feeling scary.
We cut deployment workflows from something like 8+ operational steps down to about 3 predictable ones.
Was it less architecturally "pure?" Probably.
Was it dramatically healthier for the team operating it every day? Absolutely.
## Overengineering rarely feels like overengineering while you're building it
It usually feels responsible. Mature. Future-proof.
Until your team becomes the unpaid emotional support group for your architecture.
That experience changed how I think about platform engineering entirely.
Now I care a lot more about:
- cognitive load
- operational clarity
- onboarding friction
- maintainability
- and whether the system still makes sense to the people supporting it six months later
Sometimes the best infrastructure decision is not adding another abstraction layer.
Sometimes it's removing three of them.