Aligning Project Management with Company's Values
When Mehdi and I co-founded Mergify, we didn’t just set out to create a great product—we wanted to build a company that reflected our values. Part of that journey has been rethinking project management, a task informed by years of working in organizations where “Agile” had become synonymous with bureaucracy. What started as a flexible, team-oriented methodology often felt bogged down by rituals that added complexity without delivering real results.
Over the past year, we’ve refined our project management approach at Mergify, shaping it to fit not only the needs of our team but also our belief in simplicity, ownership, and autonomy. Here’s the story of how we got there—and why building a workflow that aligns with your values matters as much as the work itself.
My Journey Through Agile Overload
When I look back at my experiences with Agile in various organizations, one story sticks out. Early in my career, I joined a team at Red Hat, one of the most functional, productive groups I’ve ever worked with. We didn’t rely on heavy Scrum processes; instead, we used a lightweight Kanban board and had stand-ups over IRC. It wasn’t fancy, but it worked. We focused on the work, not the process.
Contrast that with some other teams I observed. One team, with over 20 members, struggled to maintain a sense of ownership. The two-pizza rule, famously touted by Jeff Bezos, couldn’t have been more relevant here: a team too big to share two pizzas is often too big to stay effective. Communication is complicated, and the sense of ownership disappears.
Yet management decided to unify everyone under a single Scrum process, complete with daily stand-ups, sprints, retrospectives, and poker planning.
That did not fix the problem of the 20-person team. Even my high-functioning team began to falter under the weight of unnecessary rituals.
It was a powerful lesson: the process isn’t inherently good or bad but must serve the people doing the work.
Starting Mergify with a Blank Slate
When we started Mergify, we wanted to avoid the traps of over-engineering our processes. We began with almost no structure—just Slack messages and quick syncs to stay aligned. As the team grew, we added a daily stand-up. For a remote-first company, these short, synchronous check-ins were critical for maintaining a shared understanding, even as most of our work remained asynchronous.
Instead of following Agile dogma, we opted for a Kanban approach. Tasks moved naturally across the board with minimal friction. We didn’t bother with two-week sprints or strict velocity tracking; we let the workflow dictate the process.
And it worked; for a while.
Why Lightweight Isn’t Always Enough
Over time, cracks began to appear. One issue was ownership: who was responsible for creating cards on the Kanban board? Engineers who weren’t involved in defining tasks felt disconnected from the problem, treating the cards as instructions rather than opportunities to solve meaningful challenges. The person creating the card and the person doing the work weren’t always on the same page.
Another challenge was the endless backlog without a clear sense of what we were building or why; tasks accumulated, and the act of moving cards felt less like progress and more like treading water. The team craved a greater sense of accomplishment—a way to see their impact beyond the daily grind.
Evolving to a Project-Driven Workflow
To address these issues, we introduced a project-driven layer to our workflow. Projects became our new organizing principle: scoped pieces of work that could be completed in two to four weeks. Each project was defined by three key elements: a brief, a lead, and a deadline.
1. The Brief:
The brief outlined the problem, the goals, and the context for the project. It provided enough structure to guide the engineer while leaving room for creativity. Engineers weren’t just implementers—they were collaborators, shaping the solution as they worked.
2. The Lead:
Every project had a designated lead who was responsible for tracking progress and ensuring the work stayed on course. This wasn’t about assigning blame; it was about having a clear point of contact who could raise blockers, answer questions, and coordinate efforts.
3. The Deadline:
Deadlines were less about pressure and more about focus. They encouraged engineers to make trade-offs, prioritize effectively, and avoid over-engineering. If something couldn’t be completed within the timeframe, we adjusted the scope or deferred less critical elements.
What We Gained
The shift to project-driven work transformed how we operated. It gave engineers a sense of ownership and allowed us to ship faster, avoiding the dreaded “tunnel effect” where nothing tangible gets delivered for months. It also helped us align our priorities, ensuring that every project contributed meaningfully to our goals.
This system wasn’t just about productivity but about creating a culture where engineers felt empowered and connected to their work. It reinforced our belief that processes should serve people, not the other way around.
A few people I talked about our system thought it resembled the Shape Up methodology from Basecamp. I think it does have similarities, except that we’re a small company, meaning we don’t have enough teams to model it exactly yet. But that’s definitely a methodology that resonates with us.
Final Thoughts
Looking back, the changes we made weren’t just about fixing problems—they were about staying true to our values. At Mergify, we believe in autonomy, ownership, and simplicity, and our workflow reflects those principles.
If you’re struggling with your own project management processes, ask yourself: do they serve your team’s needs, or are they just there because “that’s how it’s done”? The best workflows aren’t the most popular—they’re the ones that align with your culture and empower your people to do their best work.
At Mergify, we’re proud of the system we’ve built, and we’re excited to keep evolving it as we grow.