The Mechanics of Mergify’s Project-Driven Workflow

In our previous post, we shared how Mergify transitioned from traditional Agile practices to a lightweight, culture-driven workflow that aligned with our values. While this approach served us well in the early days, we eventually realized that to scale effectively and maintain a sense of accomplishment, we needed to introduce more structure without sacrificing autonomy. This led us to develop a project-driven workflow—one that balances ownership, clarity, and flexibility while keeping our team motivated and productive.

Here’s how we implemented this system and why it works so well for us.

From Tasks to Projects: Shifting the Focus

The problem with a purely task-based system is that it can feel endless. Tasks pile up, backlogs grow, and engineers may lose sight of the bigger picture. To address this, we added a higher-level layer to our workflow: projects.

A project in our system represents a meaningful unit of work—a feature, a product improvement, or a significant refactor. Projects are scoped to last about two to four weeks, with three weeks being the sweet spot for most of our work. By grouping related tasks into a cohesive project, we provide our engineers with clear goals and a sense of direction.

The Key Elements of a Project

1. The Brief

Every project starts with a brief. This document, created by the project management team (usually Mehdi and me), outlines the problem, the goals, and the context. Whether the project is addressing a customer need, tackling technical debt, or experimenting with a new idea, the brief serves as the foundation for the team’s work.

The brief doesn’t prescribe every detail; instead, it provides enough clarity to guide the engineer while leaving room for creativity and problem-solving. Engineers can ask questions, suggest trade-offs, and even reshape the approach as they dive into the work.

2. The Lead

Each project is assigned a lead—an engineer responsible for driving the project forward. The lead isn’t necessarily expected to complete all the work themselves, but they are the go-to person for updates, blockers, and decisions. This eliminates the ambiguity of shared ownership and ensures there’s always someone accountable for progress.

Importantly, the lead role isn’t about assigning blame if something goes wrong. It’s about creating a clear point of contact for communication and ensuring the project stays on track. The lead’s job is to coordinate efforts, raise questions, and adapt as needed.

3. The Deadline

Deadlines might sound counterproductive in a flexible system, but we’ve found them to be invaluable—not for applying pressure, but for encouraging the right trade-offs. Without deadlines, engineers tend to over-engineer solutions, chasing perfection without considering constraints.

Deadlines create a natural feedback loop. If engineers hit roadblocks, they can bring them up early and ask critical questions like:

• “Do we need this feature now?”
• “Is this level of complexity justified?”
• “Can we adjust the deadline or scope to better fit our needs?”

By encouraging these discussions, deadlines ensure projects stay focused and deliver meaningful results without wasting time on unnecessary work.

Why It Works

1. Avoiding the Tunnel Effect

One of the biggest risks in software development is the tunnel effect, where engineers spend months on a project without delivering anything tangible. By breaking work into manageable projects with clear deadlines, we’ve maintained a steady pace of shipping new features and improvements.

Regularly delivering projects keeps morale high and gives engineers a portfolio of accomplishments to reflect on. It also helps us quickly test ideas and pivot if something isn’t working, ensuring we stay aligned with our customers’ needs.

2. Fostering Ownership and Autonomy

The project-driven system empowers our engineers to take ownership of their work. By assigning leads and giving them the freedom to make decisions, we encourage autonomy while maintaining accountability. This approach has been especially effective in identifying engineers who thrive in problem-solving roles and ensuring we hire candidates who fit our culture.

3. Improving Communication

The combination of briefs, leads, and deadlines has streamlined communication across our team. Instead of endless status updates or micromanagement, we focus on meaningful discussions that drive projects forward. Engineers know who to turn to for help, and management has a clear view of progress without needing constant check-ins.

Lessons Learned and Future Plans

While this system has been a game-changer for us, it’s not without its challenges. For example, defining the scope of a project can be tricky, especially when dealing with new or ambiguous ideas. We’ve also learned that not all engineers are equally suited to this level of autonomy, which has informed our hiring process.

As we continue to grow, we’re refining our workflow to address these challenges. One area we’re exploring is how to better support cross-functional collaboration while maintaining the simplicity of our current system. We’re also looking at ways to integrate more feedback loops into our projects to ensure we’re always building the right things.

Final Thoughts

Our project-driven workflow is more than just a system—it’s a reflection of our values as a team. By focusing on ownership, clarity, and flexibility, we’ve created an environment where our engineers can do their best work without being bogged down by unnecessary bureaucracy.

If your team struggles with motivation, productivity, or alignment, consider whether your workflow reflects your culture. Sometimes, the best solution isn’t the most popular methodology—it’s the one that works for you.

At Mergify, this approach has helped us ship faster, stay motivated, and focus on what matters: building great products.

And we’re just getting started.