I’ve never heard an engineer say, “I love our CI.”
Programming languages, editors, frameworks — sure. CI? Usually silence… or grumbling in Slack.
For me, the root cause is almost always the same: slow pipelines. And slow CI doesn’t just waste time, it actively changes how engineers work — usually for the worse.
How Slow CI Hurts Teams
I’ve been on projects where a single CI run takes 45+ minutes. The result? People batch up changes into huge feature branches so they “wait less often.” In reality, reviewers now have to sift through massive diffs, making code reviews harder, slower, and less effective.
Slow CI also kills continuous improvement. Spot a small cleanup opportunity? Rename a variable? Upgrade a dependency? You might think twice if it means an hour-long feedback loop. And when the little fixes stop happening, they pile up — leading to bigger, riskier refactors later.
Signs Your CI Is Too Slow
I’ve found these to be the big red flags:
- Large, long-lived branches becoming the norm.
- Engineers skipping full local test runs because “it takes too long.”
- People only running the specific tests they touched, never the whole suite.
Don’t obsess over a magic number for “acceptable build time” — look at these patterns. If they’re happening, your CI speed is below the productivity threshold.
Treat CI Slowness Like a Bug
The biggest shift for me was treating slow CI like a production issue.
It has a cost: wasted engineer time, reduced quality, and growing tech debt. That cost can exceed the impact of some actual user-facing bugs.
If you’re serious about fixing it:
- Make it a team goal — something measurable, like “All builds under 15 minutes.”
- Dedicate time to CI maintenance — just like you do for refactoring or bug fixing.
- Give everyone ownership — engineers should understand and influence what runs in the pipeline, not just “throw code over the wall” to some invisible process.
Show Your Tools Some Love
We’ll spend hours tweaking our editors or shell configs, but the CI pipeline is the shared tool that every engineer uses daily. It deserves the same level of care — maybe more.
A fast, well-maintained CI isn’t magic. But it will:
- Shorten feedback loops.
- Encourage smaller, safer changes.
- Make continuous improvement a habit, not a luxury.
If you want to see how I approach speeding up CI in practice, stay tuned for my follow-up on pipeline tuning for Elixir projects. And if you’re curious about our approach to macOS CI, check out Continuous Integration for Small iOS/macOS Teams.