management — jd:/dev/blog

The Problem with OKRs Isn’t OKRs

Tue, 15 Jul 2025 00:00:00 GMT

I first encountered OKRs at Datadog. They were already in place when I joined — nobody really explained the “why” behind them. You just filled out your section in the shared Google Doc. The company was growing fast, already past 1000 employees. My team was new. We cargo-culted what others were doing.

In theory, OKRs are about aligning a team around measurable objectives. You set a direction (“Objective”), define how you’ll know you’ve made progress (“Key Results”), and track it. Simple. Ambitious. Inspiring, even.

In practice? It was a glorified quarterly to-do list.

Management would come down with a spreadsheet of tasks. You could discuss the list, maybe argue your way into trimming it down. But the measure of success wasn’t impact. It wasn’t even delivery velocity. It was binary: did we check the box, yes or no?

There was no conversation about why we were doing these things. No attempt to tie work to outcomes like activation, retention, support ticket volume, user satisfaction — anything. Product management was largely absent. Engineering was expected to execute. Period.

That’s not OKRs. That’s project management theater with a quarterly cadence.

When Metrics Become a Bludgeon

Because impact could not be measured, the game became about managing perception. If your manager brought you a list of 10 items, the game was to negotiate down to 5 and deliver 6. Overdeliver by carefully managing the optics.

It became a ritual of negotiated checklists, not shared purpose. A way to evaluate individuals, not steer teams. The illusion of alignment without any of the benefits.

When we started Mergify, I brought some of that skepticism with me.

We did try OKRs — for a while. And in some areas, they worked. Marketing, for instance, benefitted from clear metrics and planning: support ticket volume, incident count, lead generation. Things we could measure and reflect on quarterly.

But for product and engineering? Not so much. We didn’t have a mature enough product management function early on. And engineers — rightly — didn’t see the value in spending hours fine-tuning quarterly goals that wouldn’t actually guide their day-to-day. (We eventually evolved to a project-driven workflow that worked much better for us.)

Eventually, we stopped.

Not because we didn’t believe in planning or goals — but because the format had become more effort than it was worth. We weren’t getting leverage from the process.

Plans, Not Rituals

What I’ve come to believe is this: most teams would be better off writing down a plan than chasing OKR perfection.

A good plan answers: what are we going to ship, why does it matter, and how will we know if it worked?

That’s it.

I appreciated how Posthog described this recently in one of their updates:

“In 2022, we required “OKRs” as part of quarterly planning, but eventually walked it back. We found engineers were agonizing over finding the right metrics, while also feeling like metrics didn't accurately reflect their subjective view of progress.”

They realized something important: even if you do write OKRs, you still need to write the plan. So maybe just… start with the plan.

Let OKRs emerge when they make sense — when you have a clear outcome to optimize for. But don’t let a framework become a crutch.

Success Isn’t a Template

We love templates in tech. We copy Google’s OKRs. Amazon’s memos. Netflix’s culture deck.

But these practices only work when paired with deep understanding. Blindly copying them won’t align your team or 10x your output.

Success isn’t a template. It’s clarity, judgment, and execution.

Sometimes that means writing OKRs. Sometimes it just means writing a plan that everyone understands — and ships.

“It’s Complicated” Is Not an Excuse

Tue, 11 Mar 2025 00:00:00 GMT

I spend a lot of time talking to engineers.

I ask them about design choices, technical decisions, and why something is built a certain way. I try to understand why this feature is so cumbersome to use, why this API is so convoluted, or why the user experience feels unnecessarily difficult.

And more often than not, the response I get is:

💬 “Well… it’s complicated.”

Sure. Everything is complicated.

That’s why you’re here. That’s why you’re an engineer.

But “it’s complicated” should never be an excuse for bad design.

Imagine If Other Professions Worked Like This

Let’s take a bakery, for example.

You walk in and ask for a loaf of bread.

The baker hands you a cup of flour and some water.

🫤 “Uhh… I was expecting actual bread.”

💬 “Well… it’s complicated.”

💬 “We’d have to mix the dough, let it rise, bake it for a while…”

💬 “That’s a lot of steps, so we just decided to give you the raw ingredients instead.”

This is exactly how software feels someday.

When users interact with your product, they don’t want to assemble the damn bread. They just want something that works.

Your job as an engineer is to handle complexity—not push it onto the user.

The Difference Between Good and Bad Engineering

Look, I get it. Engineering is hard.

Making things simple is difficult.

Abstracting complexity takes effort.

But great engineers don’t just write code—they design experiences.

A bad engineer builds something difficult and says, “Well, it’s complicated.”

A great engineer builds something difficult and makes it look simple. (More on what makes a great software engineer.)

🔹 Bad engineering forces users to deal with complexity.

🔹 Good engineering hides the complexity behind smart design.

Take Apple, for example. You know what’s actually complicated?

🔹 Compressing a 4K video into a tiny file.

🔹 Rendering realistic lighting effects in real-time on an iPhone.

🔹 Syncing all your messages, contacts, and photos seamlessly across devices.

But do Apple users ever have to think about any of that?

No. It just works.

That’s good engineering.

Stop Saying “It’s Complicated”—Start Making It Simple

When you hear yourself saying, “It’s complicated”, stop for a second and think:

🛑 Are you solving a hard problem in the simplest way possible?

🛑 Or are you just passing the complexity to the user?

If it’s the latter, you haven’t finished the job yet.

Because real engineering isn’t about making things work.

It’s about making things work… simply.

Remote Work: Great, But Not Perfect

Tue, 21 Jan 2025 00:00:00 GMT

Running a fully remote company is an incredible experience, and I say this as someone who’s been working remotely for the past 15 years and managing a remote-first company, Mergify, for the last five. Yet, after a week of in-person collaboration with my team in Toulouse, I feel compelled to reflect on what makes remote work great—and where it falls short.

Let me start by saying this: remote work is fantastic, but it’s not perfect. It’s a trade-off. Depending on your company’s stage, your team’s roles, and the challenges you’re facing, the choice between remote, hybrid, or in-office work can make all the difference.

What Makes Remote Work Amazing

The benefits of remote work are undeniable:

Focus and Efficiency: Remote work allows individuals to dive deep into their tasks without the distractions of an open office.
Work-Life Balance: Cutting out commutes and office hours lets people design their schedules in ways that suit them best.
Access to Global Talent: A remote model lets you hire the best person for the job, no matter where they are. At Mergify, this has been invaluable.
Flexibility and Autonomy: Remote work naturally fosters a culture of trust, where people take ownership of their time and deliverables.

But here’s the catch: communication in remote work isn’t as fluid as in-office communication.

Why In-Office Communication is Superior

Face-to-face communication is powerful in ways that virtual communication simply can’t replicate. It’s not just about words—it’s about body language, energy, and subtle nonverbal cues that humans naturally pick up when we’re in the same room.

When you’re remote, everything has a higher latency. Sure, you can make video calls, send Slack messages, and send emails, but it’s like having a conversation with poor reception. You’ll get your message across, but it’s less fluid and often lacks the nuances that make communication easy and productive.

Now, this might not be a problem, depending on where you work.

For startups, this trade-off is especially magnified. When you’re building something new and need constant alignment, the lack of spontaneous coffee chats and hallway conversations slows you down. Good ideas often spark from casual interactions—something much harder to replicate remotely.

The rollercoaster, that a startup is, requires sharing the energy and adrenaline that you get from awesome news and the comfort that everyone needs when some cloudy day happens. But it’s hard to get the vibe from your coworkers when they are far away. The connection is more difficult to make and maintain.

The Remote vs. Office Matrix

Consequently, the choice between remote and office work isn’t one-size-fits-all; it’s a matrix of role and company size:

Large Companies: For individual contributors, remote work can be as effective as being in the office. In large organizations, communication often requires structure anyway, and remote tools can handle most of this. However, for managers in these settings, the lack of face-to-face interaction can make it harder to truly understand what’s going on in their teams.
Startups: For smaller companies and startups, where speed, creativity, and alignment are critical, remote work becomes trickier. It’s harder to maintain momentum and cohesion when everyone is isolated. Founders and managers need to be proactive, creating systems for communication and connection that compensate for the lack of in-person collaboration.

Of course, it’s an oversimplification, and it requires nuance, but you get the gist.

The matrix also applies to roles:

Individual contributors, particularly in large companies, the need to be physically present in an office can feel unnecessary. Their work often revolves around tasks that require focus rather than constant communication or managing teams. Sitting behind a desk all day in an office doesn’t necessarily enhance their productivity or add value to their contributions.
On the other hand, managers, especially in startups, face unique challenges with remote setups. Their roles demand frequent interaction, gauging team dynamics, and fostering collaboration. Without the ability to observe non-verbal cues or engage in casual, spontaneous conversations, understanding the team’s morale and addressing issues proactively becomes significantly harder.

The same goes for seniority:

Junior employees typically require more hands-on management, regular feedback, and frequent check-ins. Without the autonomy or experience to navigate challenges independently, they benefit greatly from close guidance and structured oversight.
In contrast, senior employees tend to be highly autonomous. They often need minimal direction, excelling at managing their own work and making decisions. They are comfortable raising issues or seeking input when needed, allowing them to operate effectively with little interaction from their managers.

This is one of the reasons there has been so much vociferation against Return to Office (RTO) mandates promulgated in recent years, especially in larger companies and amongst senior individual contributors.

The Mergify Experience: Remote, But Not Alone

At Mergify, we’ve been fully remote from the start, and we’re committed to staying that way. But we know it’s not without challenges. Here’s how we’ve managed the trade-offs:

Intentional Connection: We schedule regular virtual coffee breaks to foster camaraderie and maintain a sense of community.
Quarterly On-Sites: Every few months, we bring the team together in person. Our recent week in Toulouse was a reminder of how valuable these moments are—not just for productivity but for bonding as a team. Sharing meals, brainstorming in person, and simply spending time together are irreplaceable experiences. Nothing beats your team being yelled at by the game master of an escape game for having hacked your way around the solution, in true startup spirit. 😅
Focus on Proactivity: Remote work requires deliberate communication. Everyone on the team needs to take the initiative to keep each other informed and aligned.
Hiring for Autonomy: A remote model of self-motivated, independent individuals who excel without constant oversight. Building a team with these traits has been crucial for our success. Not everyone is made for remote work. (More on this in Not Just a Job, It's a Ride.)

RTO and the Future of Work

The current trend of companies mandating a Return to Office reflects the challenges of remote work—particularly for management. It’s easier to see what’s happening, build trust, and foster collaboration in person. Yet, for many roles and organizations, remote work remains a superior option.

The reality is that no single model is perfect. For some, the trade-offs of remote work are worth it. For others, the benefits of in-office collaboration outweigh the flexibility of remote setups. What matters most is that companies recognize these trade-offs and build systems that suit their unique needs

Remote work is here to stay, but it’s not a panacea. It’s a trade-off between flexibility and connection, efficiency and spontaneity. At Mergify, we’ve embraced remote work with open eyes—recognizing its strengths while finding ways to address its weaknesses. Whether remote, hybrid, or in-office, the key is to adapt, experiment, and keep evolving.

What’s your take on the remote vs. office debate? Let me know in the comments or reach out—I’d love to hear how others are navigating this shift.

Aligning Project Management with Company's Values

Tue, 10 Dec 2024 00:00:00 GMT

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.

The Shape Up methodology

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”? (I wrote about a related frustration in The Problem with OKRs Isn’t OKRs.) 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.