Unifying Automation at GitLab: A Decentralized Rule Engine

At GitLab, automation was quietly fractured. Over time, more than 23 entry points and 16 different functions had evolved to include some form of conditional logic—triggering actions based on user-defined inputs—but they had been built in silos by independent product teams. There was no shared framework, no consistent UX, and no unified vision. Debugging was painful. Visibility was limited. Race conditions were common.

One day, I caught wind of an engineer exploring a new automation feature in isolation. I immediately recalled prior research—AppSec JTBDs, contextual inquiries, and journey mapping—that made it clear this was a recurring, systemic pain point. There was no PM, no roadmap, no plan, but I knew this was the opportunity to address it. I reached out, and we teamed up.

Seize an early opportunity to solve a long-standing, cross-cutting problem:

Unify automation into a scalable, coherent system that could be adopted across the product—without a PM, formal team, or initial roadmap.

I began by conducting a product-wide audit, identifying all the fragmented touchpoints where automation already lived. Each of them had evolved to solve a narrow use case, but together they painted a picture of hidden complexity and user burden.

From that insight came a core design principle:

Instead of centralizing ownership, we’d decentralize it—giving each product team the ability to manage their own logic using a shared framework of components, templates, and logic handling.

We designed a flexible system grounded in cascading inheritance—write-down, read-up—allowing group-level logic to flow down to projects while supporting overrides and respecting permissions. This inverted GitLab’s legacy model, which often started at the project level and added complexity as it scaled up.

To avoid overwhelming users, I introduced a library of customizable prebuilt automation templates. This drastically reduced friction and avoided the “paradox of choice” often seen in power-user features.

Since no formal team existed, I partnered with a Staff Engineer and later brought in a PM from a related group, who acted as a liaison while still supporting their area. Together, we planned the project across three strategic phases:

• Minimal (alpha): Project planning automation
• Internal and private beta: Source control and code review automation
• Viable (public beta): Security, compliance, and operational automation

To validate the system, I ran structured A/B and B/A usability testing with 12 participants aligned to four primary personas. Each participant completed two tasks using both the legacy and new experience. We observed their flows, captured success rates, time on task, reliance on documentation, and gathered qualitative feedback. Based on the results, we refined the interface and clarified how users received feedback during automation creation.

With early data and a shared vision in hand, we aligned with the VP of Product and three senior PMs overseeing six disparate teams. Despite initial skepticism from some teams—concerned that their users wouldn’t be able to manage the logic—we demonstrated that our system not only worked but dramatically outperformed the status quo.

Within three months, we shipped an internal and closed beta. After 30 days, we saw:

• 15% increase in usage
• 37% increase in automation run rate
• 28% reduction in errors compared to legacy automation

Despite our success, GitLab underwent company-wide layoffs in 2021. The Special Engineering Group was disbanded, and without a formal team to carry the work forward, the project—still in closed beta—was eventually deprecated. But the problem remained solved in principle, and the foundation we laid proved that scalable, decentralized automation at GitLab was not only possible—but necessary.