What Senior Engineers Actually Mean When They Say 'It Depends

Hearing "it depends" from a senior engineer is maddening when you're the one waiting for a straight answer. A junior engineer wants a fix. A mid-level engineer wants a recommendation they can implement by Friday. What they get instead sounds like a dodge, like the engineer either doesn't know the answer or doesn't want to commit to one. This reading is almost always wrong, and the article's job is to show what is actually happening when an engineer says it.

The surface interpretation treats "it depends" as evasion, a lack of confidence, or an unwillingness to take a position. What's actually happening is narrower and more deliberate: the engineer has already spotted that the question hides variables that would change the answer, and the phrase is a signal that evaluation has started rather than finished. A junior engineer pattern-matches the question to a solution they remember working before. A mid-level engineer reasons forward from the tools they know well. A senior engineer reasons backward from constraints they've diagnosed first. That's a different cognitive move entirely, not a softer version of the same one.

The gap this creates has real consequences for careers. An engineer who hears "it depends" as evasion keeps pattern-matching their way through decisions, and that habit caps how far their judgment can grow. An engineer who says "it depends" without doing the underlying work is faking the sound of seniority without the substance behind it, and peers notice eventually. The rest of this article unpacks what the real version of that phrase contains, making the real version visible instead of assumed.

What the phrase depends on: five axes senior engineers use

Senior engineers don't run one general-purpose gut check when they say "it depends." They scan across five distinct axes of context, and any one of them can flip what the right answer is. In practice, these axes run simultaneously, not in sequence. A senior engineer doesn't finish checking reversibility, then move on to org maturity, then move on to role scope. All five get weighed at once, which is part of why the process looks instant from the outside even though it's doing real work.

The first axis is reversibility. The most expensive decisions are the ones that are hardest to undo: architecture choices, data model commitments, vendor lock-in. A senior engineer weighs how reversible a decision is before weighing how fast it can be executed. A mid-level engineer, by contrast, tends to optimize for shipping first and worry about reversibility later, if at all.

The second axis is company stage and organizational maturity. The MetaCTO AI-Enabled Engineering Maturity Index defines five organizational stages, from Reactive at Level 1 up through AI-First at Level 5. A senior engineer working inside a Level 1 org and a senior engineer working inside a Level 5 org can share the exact same title while facing completely different optimization surfaces. What's right for a startup still hunting for product-market fit is not what's right for a company running production AI across its full development lifecycle, and an engineer who doesn't read which environment they're in ends up applying solutions built for the wrong context.

The third axis is role scope, specifically the line between architecture and feature execution. Senior engineers evaluate impact ahead of time and choose the highest-priority problems to work on; at most, they're handed a problem space by their manager, never a pre-selected solution. Saying "it depends" is partly a signal that the engineer is operating at the level of the problem space, not the level of a single solution. A mid-level engineer asked "should we use Redis here?" names a database to use. A senior engineer asks what problem Redis is being asked to solve, and whether that's even the right problem to be solving in the first place.

The fourth axis is which kind of engineer is actually being asked the question. Titles like "AI engineer," "ML engineer," and "research scientist" point at genuinely different optimization targets. The right answer to "how should we evaluate this model?" depends entirely on whether the person answering is judged on scientific insight, production performance, or customer impact. The same question lands differently depending on which tradition the speaker comes from, and a senior engineer accounts for that before answering.

The fifth axis is the trade-off surface itself: latency, accuracy, complexity, cost. Production AI systems force explicit reasoning across competing constraints. A system tuned for latency trades away some accuracy, and a system tuned for accuracy trades away some latency. A senior engineer names which constraint is the dominant one before recommending anything at all. On this axis, the senior engineer uses all five axes to identify which constraint actually dominates in this specific situation, then commits to an answer built on that.

Why this framework only becomes visible at the senior-to-staff boundary

This framework appears unevenly across career stages, crystallizing at a specific inflection point, and that's why senior engineers tend to reason this way almost universally while most mid-level engineers haven't gotten there yet. The "it depends" framework activates at the senior level because that's the first point where the engineer is responsible for selecting which problem to work on, not just for executing a problem someone else already scoped. A mid-level engineer can complete most of their work independently, but that work typically arrives with relatively little guidance on a problem that's already been defined by somebody else higher up.

Advancement at senior and above runs on scope, ownership, and cross-team impact, not years logged with a particular toolset. That's why tenure alone doesn't produce this framework. An engineer can spend years executing mid-level work competently and still never develop the habit of scanning constraints, simply because nobody has asked them to own the problem space yet. The framework is a response to a specific kind of responsibility, not a reward for time served.

The jump from senior to staff pushes this even further. Staff engineers set technical standards across multiple teams and own the AI platform that other engineers build on top of. At that level, "it depends" addresses not one system's trade-offs but which direction an entire organization should move. The scope of the question changes, but the underlying method, scanning constraints before recommending, stays the same.

Some mid-level engineers already reason this way, and those are precisely the engineers who are ready for a senior title. The framework doesn't appear the moment someone gets promoted. The promotion is recognition that the framework was already running before the title caught up to it.

How organizational context puts a ceiling on developing this judgment

Technical skill alone doesn't produce senior-level judgment if the environment never forces an engineer to use it. An engineer can't fully develop the constraint-scanning habit if their organization never puts them in front of the kind of constraints that require it. A senior engineer working at a Level 2, or Experimental, organization will struggle to build staff-level judgment, because that organization isn't yet running the cross-team AI systems that demand that kind of thinking. The ceiling on someone's judgment is often set by their environment, not their ability, which is one of the most underappreciated factors in AI professional development. An engineer can be technically excellent and still plateau, simply because the surrounding environment never generates problems big enough to force constraint-scanning at scale.

This limitation isn't confined to staff-level ambitions. This limitation is also visible at the senior level. An engineer who has only ever been handed pre-scoped tasks, and never asked to own the problem space itself, has never had occasion to run the framework at all, no matter how many years they've spent writing code.

That has a practical implication for anyone evaluating a new role. Before accepting a position, evaluate the organization's AI maturity level and the actual scope of problems the role is given ownership over, not the tech stack or the size of the team, since that predicts more about career growth than almost anything else in the job description.

This also explains a lot of the title inflation across the industry. A "Senior Engineer" at a Series A startup might be doing work that would be classified as Staff level somewhere else. The title itself doesn't reveal whether someone has actually been asked to run the constraint-scanning framework. It only reveals what word the organization decided to use.

Why "it depends" is a method that terminates in a committed recommendation, not a destination

The single biggest misuse of "it depends" is treating it as a finish line instead of a process. Genuine seniority means using the phrase to open an evaluation and then closing that evaluation with a committed, reasoned recommendation. It depends" can mask indecision, or cover for an engineer who has never learned to form and defend an opinion, and that objection is fair and worth taking seriously. Interviewers notice this. Peers notice it too, and it erodes trust quickly once it's spotted.

The correct version of the move is to name two or three viable approaches, lay out the trade-offs explicitly across latency, accuracy, complexity, and cost, then pick one and defend it. The senior skill is using the phrase as a structured method that terminates in an actual recommendation, not landing on "it depends" and stopping there. This is what separates real senior judgment from language that merely sounds senior. Anyone can say "it depends on the scale and the team's expertise."

The framework also has to account for who's listening, not just what the technically correct answer is. An engineer with deep infrastructure expertise, strong in core systems programming and a low-level hardware toolkit, can walk into an interview loop and get rejected for not knowing a particular trendy framework, even when the underlying engineering judgment is sound. That mismatch illustrates a real risk: the constraint-scanning framework only pays off when the organization on the other end is actually evaluating for depth of reasoning rather than surface familiarity with a specific tool. A research-trained engineer and a production-trained engineer might both say "it depends" in the same meeting, but they're scanning different axes to get there. What separates them is whether the answer eventually lands on a concrete, defensible position, or just trails off into a longer list of factors to consider, not which axes they used.

The practical lesson here is to force the evaluation to a close, commit to a recommendation, and then stress-test that recommendation against the same axes used to build it, rather than to accumulate more context before answering.

What this means for engineers trying to develop the framework deliberately

The "it depends" framework is a learnable habit, not a fixed trait some engineers have and others don't. Building it takes deliberate practice across the five axes, not just years of accumulated experience and the hope that judgment appears on its own.

Start every technical decision by naming the constraint it's actually optimizing for. If that constraint can't be named, the recommendation isn't ready yet, no matter how confident it sounds. Seek out environments that force constraint-scanning rather than waiting for one to find you. Joining a team operating at Level 3 or Level 4 AI maturity gives access to real architectural decisions, real production incidents, and real cross-functional strategy work that no course or certification can substitute for. When giving a recommendation, say: "this is the right call if X is the dominant constraint, and if Y is dominant instead, the answer changes to Z. That habit trains the underlying reasoning and makes it legible to collaborators and managers who are trying to evaluate judgment, not just output. Treat mismatches between title and actual scope as diagnostic information rather than just a compensation complaint. Titles don't translate cleanly across companies, and a "Senior" title at one organization might mean the person holding it has never once been asked to run this framework. Understanding that helps engineers aim at the right environments, not just chase the next title up the ladder.

This also matters for how engineers document their own growth. Promotion packets should tie impact directly to a company's leveling criteria and focus on outcomes rather than a list of tasks completed. An engineer who has been making their constraint-based reasoning explicit, on paper, in design docs, in recommendations, already has documentation of senior-level thinking built before the promotion conversation even starts. How its senior engineers answer ambiguous questions, and whether "it depends" is allowed to run its full course or gets overridden the moment a manager states a preference, often reveals the quality of an engineering organization. An organization that cuts the process short before it reaches a recommendation is an organization where this judgment will stop growing rather than sharpen.