"It Depends" Is the Phrase I Hate the Most

Introduction

“It depends.”

Somewhere along the way, this phrase became every engineer’s go-to answer. How should we design the architecture? It depends. Should we go with microservices? It depends. Which framework should we use? It depends.

And they’re right: there are no silver bullets in software development, and every technical decision is contextual. But this phrase does nothing to help move the project forward.

In Japan, engineers often like to use the phrase “技術的に可能です” (technically possible) to indicate that something can be done, but they probably don’t want to do it—a polite, indirect refusal.

So Right It’s Meaningless

You share a perspective, and they reply with “it depends.” You probe further, and you get another “it depends.” In the end, everyone reaches a consensus of having no consensus at all, and the meeting is adjourned.

“It depends” is technically correct in almost every situation. That’s precisely why saying it is as good as saying nothing. It’s like someone asking how to control the heat while cooking, and you answering, “The key is the heat.”

Conversely, if someone says “it depends,” it might also mean your objective isn’t clear enough. Not knowing how to make a decision in that context, they give a vague response instead.

That’s why whenever I lead or participate in discussions, I make a point of sharing the goals and context in advance. Only when everyone is aligned can we actually find a solution. Take a look at an article I wrote earlier—Baskets and Spears: Are you all looking at the same landscape? Or is one person looking at an orchard while the other is staring into a jungle?

Why We Struggle to Make Decisions

Having no opinion isn’t inherently wrong. In the book The Soul of Perfect Decisions, it’s mentioned that situations can usually be categorized into three buckets:

• Decide immediately
• Insufficient information
• Decision deadline

In my view, the inability to make a decision or offer an opinion usually boils down to a lack of information. This is also the easiest issue to resolve—both sides just need to bridge the information gap. Not having an opinion can actually be an honest way of expressing yourself. You can say, “I don’t have enough information to judge.” If you’re unfamiliar with the domain, you can say, “I don’t know much about this area; I’ll defer to you guys first.”

Next time you encounter “it depends,” try asking them:

1. So, what is your opinion?
2. What information do you need to help you decide?
3. What is your goal in saying that?

How to Actually Move a Project Forward

“It depends” used to be my benchmark for judging whether someone was a senior engineer. To me, it signified making trade-offs and clarifying requirements—no longer just focusing on cranking out features.

Yet this maturity can easily turn into the arrogance of neutrality. Because there are so many factors to consider and you’re afraid of being wrong, you brush off what needs to be done with a simple “it depends.”

It’s a form of self-deception. The end result? The person who contributed nothing claims the moral high ground, while the people genuinely trying to work through the discussion look immature.

The real way to move a project forward is to responsibly bear the weight of “it depends”: organizing arguments, clarifying stakeholder needs, prioritizing, filling in missing information, and proactively communicating.

• Which side takes priority this time?
• Under what conditions would this priority be reversed?
• Who bears the cost of this trade-off?
• If we make the wrong call, which direction is easier to recover from?
• Is this a matter of principle, or an exception for this specific case?

Only when you push the discussion to this level of granularity does “balance” become actionable. Then, decisions can be made and consequences owned. If it’s wrong, conduct a retrospective, adjust, and push forward again.

By the same token, saying “focus on results, not process” is easy, but it shouldn’t be used as an excuse to dodge process improvement. Sprinting can deliver short-term results, but you can’t rely on sprinting forever. Failing to improve your processes is just mortgaging your future.

Let me share a few examples. Over the course of my freelance and contracting work, I’ve run into discussions like:

• Should we use MySQL or PostgreSQL?
• Should we use a monorepo or separate repos?
• What programming languages should we use for the frontend and backend?

None of these discussions have a single correct answer. If left to open-ended team debate, they often devolve into meetings with zero conclusion.

“Both MySQL and Postgres are fine.”

“A monorepo seems easier to manage, but separate repos make sense too.”

When running a project, discussions that fail to push things forward are my biggest pet peeve. That’s why I prepare the data beforehand to convince the team. On the surface, the meeting is about deciding the tech stack; in reality, it’s about conveying my conclusion to the team. As for how to evaluate these decisions, you can check out my previous posts:

Boring Technology 通常有「引入某個新技術」可以解決既有問題的想法，大多代表開發還沒有想得足夠清楚而已。不過要體悟這件事，通常需要時間積累。從碰到新技術眼睛會發光的少年到變成油光滿面的中年大叔。 random

I do my best to shoulder the weight of “it depends,” explaining to the team why I made that call—factoring in recent industry trends, the client’s current tech stack, and their environment. (And sure, you can also package your personal preferences to guide the team in the direction you want.)

Even if that means taking on the risk of being wrong, it’s infinitely better than being the person who only knows how to say “it depends” and later chime in with “see, I told you so.”

I’ve learned this the hard way in the past. Even when I knew a team discussion was unproductive, I kept quiet. Subconsciously, I assumed speaking up wouldn’t change anything, so I’d just vent on social media to seek validation and move on.

Conclusion

Don’t just toss around “it depends.” Articulate what the “depends” actually hinges on. What is the current situation? What priorities should we focus on? How can we make a decision that helps the project move forward? It’s easy to stand on high ground and cynically sneer. Getting your hands dirty, convincing others that your plan works, moving the project forward one step at a time, and marching forward while carrying the full weight of “it depends”—that’s infinitely cooler.