Lorenzo Mele / Greenkey

REFINE method to propose changes in the system

This REFINE framework gives you six lean steps—scaled to the size of your idea—that ensure every proposal is grounded in real problems, history, and impact.

Introduction

I've noticed that sometimes, even experienced developers propose solutions that could benefit from additional refinement. They might make assumptions about past decisions or suggest that adopting a new tool will solve everything without fully exploring the context.

Even if you're not writing a full-fledged proposal document, this framework will help you clarify your idea and make it stronger. Each step requires work that should, of course, be proportional to the "size" of the proposal. If you're proposing a small change, you don't need to do extensive research, but it's useful to spend a few minutes on each step so you can explain your idea better.

Here’s the REFINE method for proposing system changes, a structured framework that helps developers create stronger proposals:

R – Recognize the problem

First, as developers, we solve problems—so let's start there.

What exactly is the problem? Why is it problematic? How is it affecting us or our users?

Focus solely on the problem here—not the solution. Avoid comparisons and discuss only the specific issues causing difficulties. Present tangible problems with objective evidence, not opinions. When possible, include metrics (e.g., "this causes us to spend an extra hour of work every time we change X"). Or describe objective consequences (e.g., "this makes the design more complex due to coupling/obscurity/etc.").

Be prepared to defend your problem statement! What you perceive as a problem, others might view as a desired behavior. In such cases, be ready to explain why it's problematic from your perspective.

Examples:

E – Examine why it's this way today

Second, why is it this way now?

Perhaps we decided to use Pydantic four years ago because it was trendy, or maybe it was a choice made with careful consideration of the context.

Try to find the original discussion—the PRs that introduced it might help—so you can see if the context has changed since then.

If you cannot find the original discussion, ask! Asking why a choice was made is an exceptional way to learn. And if nobody knows, then there's a good chance that your proposal will stick.

You might discover there's actually a good reason for the current implementation.

Finding historical discussions or PRs isn't always feasible. Relying on memory or anecdotal evidence from team members can introduce bias. Without proper context, you risk proposing solutions that repeat past mistakes or fail to address the underlying reasons for the current implementation. If documentation is lacking, speak with multiple team members to triangulate the most accurate historical perspective.

Here are some useful questions to facilitate the conversation:

F – Formulate your solution (high‑level → detail)

Next, it's time for what we're all accustomed to doing: proposing a solution.

Describe your solution in simple terms and explain why you're proposing this specific approach rather than alternatives. Clarify why you believe this is the best way to address the problem. Does it offer additional benefits? If so, are they relevant to our needs? (e.g., "This will allow us to convert objects to JSON"—but do we actually need that capability?) If not, omit mentioning these peripheral benefits, as they might derail the discussion from the main problem we're trying to solve.

Then detail how the solution could be implemented—include technical specifics, perhaps with a draft PR, demo code, or similar examples. If creating these would require significant time, acknowledge this in your proposal and offer to provide examples if needed. Remember that "seeing is believing"—tangible examples make your solution much more compelling.

If you're hesitant to invest substantial effort into something that might be rejected, that's understandable. However, remember that even "rejected" proposals often contribute valuable insights to the team's thinking. Consider starting with a simplified version of your proposal to gauge interest before diving deeper. This doesn't mean skipping steps—just making them lighter—while still demonstrating that you thoroughly understand the problem.

If you're aware of alternative solutions, acknowledge them and clearly explain your reasoning for not selecting them.

I – Investigate impact (cost/benefit, short & long term)

Every change requires effort. Why should we make that effort? What would be the benefit?

What is the benefit of the proposed solution? Make it tangible—all the hints given to describe the problem are also valid here. Remember that the benefits might come from both user and business perspectives!

How much will it cost now to change the code?

How much will it cost in the long run? Is it adding a burden to future development?

Don't overestimate the benefits—be realistic.

Be honest about downsides. You shouldn't "sell" your idea; you should prove it's valid. If certain things will become more difficult, acknowledge them. It can be useful to mention even non-relevant downsides to prevent unnecessary side discussions (e.g., "Pydantic will make X more difficult, but we're not doing X at the moment").

Consider the current system architecture and constraints. A solution might look good on paper but could be impractical due to existing technical debt or infrastructure limitations.

Also remember that change can be iterative—perhaps the solution can be made smaller to reduce costs and risks.

Assessing cost/benefit is a huge topic—I'm sure there are plenty of essays on how to do it—but here are some hints to consider both quantitative and qualitative factors:

What about intuition?

Some people might feel the proposed solution is right based on their experience.

I would suggest trying to understand where that intuition comes from: there might be some bias, or you might discover an objective reason behind it.

In any case, this framework won't prevent you from proposing ideas, but being aware that your proposal stems from a "gut feeling" is important when trying to convince the team.

N – Negate it (play devil's advocate)

After all this work, you might discover that you struggle to find compelling reasons for the change. In this case, you'll likely conclude it was a decent idea but not worth pursuing.

If you still feel it's a good idea, examine why. Is it simply because it's cool or because you personally like it? While exploring innovative approaches is part of our job, it must happen at the right place and time. Not all teams have the capacity for experimentation that might create additional work or introduce risks.

Try taking the opposite position (devil's advocate)—and do this sincerely, not mockingly. You need to genuinely believe the counterargument for this exercise to work. Consider what the smartest people you know would argue against this solution. If their reasoning would convince you, it's probably best to move on.

Another question you can ask yourself is: what would make me change my proposal? E.g. if someone showed me benchmark data proving my solution would be slower, or if there were compliance issues I hadn't considered, would I be willing to revise or abandon my approach? Being able to articulate your own threshold for changing direction demonstrates intellectual honesty.

If you're uncertain, start by discussing your idea with someone you trust. They'll provide a valuable "reality check." Ideally, choose someone familiar with the system who can help you gather relevant information.

E – Encourage criticism and iteration

You're finally ready to present your idea.

It's useful to start discussing your idea with someone on the team, as mentioned in the "negate it" step. This will help build consensus or further refine the idea.

Even when pitching your idea to someone you trust, it's crucial to maintain openness.

Encourage colleagues to share how they'd tweak or extend your proposal.

It's okay if you don't see the whole picture.

You're not perfect—nobody is—and neither is your solution.

There are many things you don't know, and your choices might change based on information others share with you.

Don't fall in love with your idea. This isn't a competition to determine who has the best idea. Remember: we're here to solve problems, and every decision will impact the entire team, so it must be a team decision.

Finally, this guide assumes rational participants, though even a well-crafted proposal can turn into a debate driven by status, ego, or prior preferences. It's important to distinguish between rational and irrational arguments (from both sides!) and maintain a civil conversation. The ultimate goal is to solve problems.

How to present the proposal

Although you should understand the current setup, your tone might still come across as "the current state is bad, let me fix it," especially when viewed through the lens of team dynamics or ego.

Here are strategies to handle feedback effectively

Remember that the ultimate goal is not to "win" an argument, but to collaboratively arrive at the best solution. The most successful proposals often emerge through multiple iterations informed by diverse perspectives.

Conclusion

This is not a perfect method, but I think it addresses the major problems I see whenever proposals are presented. While it might seem daunting at first, I encourage you to try it and share your feedback. With practice, this approach will likely become second nature, and you won't even need to consciously review the steps.