Loading request...
A Spacelift customer experienced a significant decrease in velocity because they applied the same rigorous GitOps flows, policies, and approvals to all environments, including development and temporary databases. This 'one-size-fits-all' approach for policy enforcement made every decision feel like a 'board meeting,' even for non-mission-critical tasks. The tool should provide mechanisms to apply different levels of policy enforcement or approval workflows based on the environment or resource type to avoid over-formalization and maintain velocity.
We pick tools to solve problems. But they also end up shaping how we think and work. I learned that from a Spacelift customer who did everything “right.” This customer loved Spacelift so much they ran everything through it with the same GitOps flows, policies, and approvals: Production deployments Dev environments Temporary test databases It gave them full visibility and ironclad control, and they wanted that everywhere. A few months later, their velocity tanked. Ironically, Spacelift was doing exactly what it was supposed to: every change tracked, policy enforced, and audit trail pristine. The problem was that they used it to treat everything like it was mission-critical. As their lead engineer put it: “We turned every decision into a board meeting.” They’d made infra so formal that experimentation became friction. “Let me try this” turned into “let me draft a PR, request two approvals, and wait for policy checks.” The platform shaped the culture, and suddenly everything felt like production even when it was it. That conversation changed how I think about tooling. This wasn’t a bad setup; I would’ve built something similar. The mistake was using it everywhere. You need escape hatches. Places where people can move fast, test ideas, and break things safely. Because even the best tool becomes a constraint when it’s the only tool you allow.