Stop Saying “It Depends.”
“Well, it depends.”
We love saying it. We think it signals to the room that we grasp the vast, complex, multi-dimensional chess game of software architecture.
We think it makes us sound incredibly smart.
In reality? You are doing one of two things: dodging the responsibility of making a hard call, or quietly bragging about your own technical brilliance without providing a single shred of actual value.
Let’s be brutally honest. Most of the time, we retreat into “it depends” because we simply do not know what our boss wants to hear. Playing it safe, we list out every conceivable option.
But realize what happens in that exact moment: you are delegating your responsibility upward. By forcing your boss to sift through the options and make the final call, you render yourself virtually useless. You are acting as a researcher—a role that can now easily be replaced by AI—instead of doing the hard work of making a decision and owning the consequences.
Stop doing it.
You are in the room because you are an expert. No one is asking you for a philosophical dissertation on the infinite possibilities of system design. They did not come to you to buy more uncertainty, to get more problems, or to leave with more questions than they walked in with.
Handle it entirely differently. Rather than endlessly deliberating, bring a maximum of two options to the table and state: “I chose the first option, and I am moving forward with it unless you clearly disagree and tell me what I should do instead.”
In this scenario, you show that even if they abstain from making the decision, you are ready to act. You picked your way. It forces a clean resolution: they either give you the green light (which is exactly what you want), or they actively step in and put their own alternative on the table.
If you truly do not know the answer, do not hide behind the illusion of complexity. Just say, “I don’t know.” It takes far more confidence to admit ignorance than it does to waffle.
But if you do know, cut the bullshit. Stop acting like a consultant and start acting like a Product Engineer.
Product Engineering is not about listing every possible edge case; it is about bringing clarity, hard numbers, and hypotheses you are willing to validate. It is about understanding the current telemetry—both technical and product—and defining exactly what scale you can handle, what scale you predict, and which friction points you are going to erase.
Let me give you a concrete example. Recently, one of my principal engineers for platform engineering came to me about a massive infrastructure rearchitecture. He didn’t start drawing boxes and arrows, and he didn’t give me a list of “it depends” scenarios.
He asked a direct question: “What growth are we assuming in the next few years? 2x, 5x, or 20x?”
Then he laid out the reality, with absolute, ruthless clarity:
If we plan to scale 2x-5x: We don’t have to do anything. We just keep going and maintain the current infrastructure.
If we anticipate 10x-100x growth: Our current infra will collapse. The costs will skyrocket to X. We will hit hard database limitations, like MongoDB’s 16MB document limit. Here is exactly where we are duplicating data unnecessarily, and here is the architecture that will cut our running costs by 20-50%.
There was no “it depends.” There was pure math, clear options, calculated risks, and hypotheses he was taking absolute responsibility for.
Next time you are asked for a technical direction, use this exact framework. Bring exactly two options to the table:
1. The Recommendation (Your Choice)
This is the path you are putting your name on.
The Math & Telemetry: What is the specific volume this will handle? What do our current product metrics tell us this will solve?
The Hypotheses: What are the core assumptions you are making, and how will you validate them in production?
The Friction Erased: Exactly which bottlenecks (technical or user-facing) are removed?
The Concrete Risks: What will inevitably break, cost money, or hit a hard limit at scale?
2. The Alternative (The Fallback)
This is the viable second path, presented solely to frame the concrete trade-offs of the first.
The Distinction: How this fundamentally differs from your recommendation in terms of architecture or product capability.
The Costs & Opportunities: The exact difference in time, capital, and engineering hours.
The Losses: The specific market opportunities, performance metrics, or scaling multipliers the business explicitly sacrifices if they reject your recommendation.
That is it. You lay out the map, point to the destination, and highlight the cliffs with cold, hard numbers.
Your job as an engineering leader is not to map out every single blade of grass in the valley of possibilities. Your job is to lead your team and your stakeholders through it. To make the decision. To clear the fog.
Take the damn responsibility for it.
Need some inspiration?
Have a look at: