Tell Me Why Your Method Is Better

As a manager, if I propose a solution and someone on the team has a better way, all they need to do is defend their method, and we’ll use it.

This approach isn’t just about encouraging collaboration. It’s about building a process where ideas are carefully examined, researched, and backed by evidence. Let me share a story from my first job to illustrate why this method works so well.

At my first job, my team was tasked with adding a new feature to a service that ran on millions of devices. The task fell to me, the newest and least experienced developer on the team. Imposter syndrome hit me like a truck. I kept asking myself: Why would they entrust me with such a big responsibility?

The requirements for the feature were clear, but as I read through them, something felt off. The managers had essentially written a blueprint on how to implement the solution, down to recommending specific HTML5 tags and experimental JavaScript features. At first glance, they seemed confident in their plan.

The task was to implement a tracking script that would run on all the websites the company owned. However, as I read deeper, I realized their blueprint included experimental technologies that weren’t supported by the majority of our users’ browsers. Most notably, Internet Explorer. They’d even recommended a "copy and paste" implementation of their code into our project.

I immediately flagged this to my lead developer. “This isn’t going to work,” I told him. He looked at the ticket, reviewed the managers’ notes, and responded, “It looks fine to me. What exactly is the problem?”

The truth was, I didn’t yet know how to articulate why the solution wouldn’t work. I just knew it wouldn’t. My lead didn’t dismiss me. Instead, he challenged me: Do the research, find a better implementation, and be ready to explain why your method is better.

So I dove in. I began by researching why the proposed solution would fail and what a better alternative might look like. I found that HTML5 tags weren’t supported in Internet Explorer at the time and that relying on experimental JavaScript features would likely break the functionality for the majority of our users. I learned about feature detection and how it could provide a more robust solution than the outdated Internet Explorer-specific comment tags.

Once I had the evidence, I wrote a detailed document outlining my findings, proposed an alternative solution, and even included a working prototype. My lead insisted on the prototype because, as he put it, “If you can show it works, it’ll be hard for them to argue.”

Sure enough, when I presented my research to the managers, they disagreed initially. They defended their original blueprint, but I had the prototype to back me up. I showed them, in real time, how their solution failed and how mine worked seamlessly, even in Internet Explorer.

In the end, my implementation went live. My code was running on millions of devices, and I learned an invaluable lesson: It’s not just about knowing something won’t work, it’s about being able to explain why and presenting a better way forward.

The Role of Research and Debate

This experience shaped how I approach problem-solving as both a developer and a manager. When disagreements arise about how to proceed, the solution shouldn’t be dictated by authority. It should be guided by merit. That’s why I encourage team members to research their ideas and defend them with evidence. This process not only ensures we choose the best solution but also helps the team grow by diving deeper into the problem.

As a manager, I’ve learned that my job isn’t to have all the answers. It’s to create an environment where the team feels empowered to challenge ideas, defend their methods, and collaborate on finding the best way forward.

Embracing Collaboration

A good manager doesn’t just accept the first solution. They ask questions, encourage dissent when necessary, and ensure the team documents their decisions. Even when the team can’t reach unanimous agreement, documenting the decision and concerns raised ensures we can revisit and learn from it later.

This approach creates a culture of collaboration, where the best ideas rise to the top. Not because of who suggested them, but because they were carefully examined and proven to work.

So, if you have a better method, tell me why it’s better. Research it. Defend it. And if it holds up, we’ll use it. That’s how you build better solutions and a stronger team.

---