There's a question I ask very often when a team shows me a solution:

Why did we do it this way?

I don't ask because I'm expecting a particular answer or because I assume there's necessarily a better solution. I want to understand the decision. And there's one answer I hear surprisingly often:

“Because it was already built that way.”

That's usually where I stop.

Not because the decision is necessarily wrong, but because we've stopped talking about a decision and started talking about an inheritance.

Every Decision Once Had a Context

Behind almost every system there's a story. Maybe the company needed to launch quickly, the team was much smaller, a particular technology was the only option available, or a customer urgently needed a solution. Maybe someone simply made a reasonable decision with the information available at the time.

The problem isn't inheriting decisions. It's inheriting them without also inheriting the reasoning behind them. The context may have changed completely while the solution remained the same.

The Answer I'd Like to Hear

When I ask why we do something a certain way, I'm not necessarily looking for a long technical explanation. An answer like this is much more valuable:

“We made this decision for these reasons. These conditions are still valid. If any of them change, we should revisit it.”

There are three important elements in that answer:

  1. Reasons: we know why the decision was made.
  2. Assumptions: we know which conditions make the decision still valid.
  3. Triggers: we know what would need to change for us to reconsider it.

That turns an inherited decision into one we can still explain.

But that raises another question.

Where does that explanation live?

Decisions Need Memory Too

If the reasoning behind a decision exists only in the head of the person who made it, sooner or later we'll lose it. That person may change teams, move into another role, or leave the company. Months later, someone will find the solution, ask why it works that way, and receive a perfectly honest answer:

“Because it was already built that way.”

One simple mechanism for preventing this is an Architecture Decision Record (ADR). ADRs don't need to be large documents. For many decisions, it may be enough to record:

  • the problem we were trying to solve;
  • the decision we made;
  • the alternatives we considered;
  • the main assumptions behind the decision;
  • and the conditions that should cause us to revisit it.

In fact, the answer I'd like to hear from a team is essentially a condensed ADR:

We made this decision for these reasons, under these assumptions, and we know what would need to change for us to revisit it.

Documenting decisions doesn't eliminate bad decisions. It prevents something different: losing the context behind both the good ones and the bad ones.

How We Ask Matters Too

There's something I've learned over time: when the question “Why did you do it this way?” comes from a CTO or anyone in a leadership position, it may not sound like curiosity.

It can sound like an audit.

That's why the intention and the way we ask matter.

Instead of:

“Why did you do this this way?”

I prefer something like:

“What problem were we trying to solve when this decision was made?”

I also often clarify my intention from the beginning:

“I'm not saying we should change it. I want to understand why it's this way.”

And whenever possible, I prefer these conversations to happen with the team rather than as a private interrogation. The goal isn't to identify who was responsible for a decision. It's to reconstruct the context that made the decision reasonable — or discover that it no longer is.

Take a Few Steps Back

When a team is developing a feature, it's naturally focused on solving the problem directly in front of it. That's necessary. But I often find value in stepping back and looking at the entire problem. Suppose we're adding a new condition to a process. We can simply add another if.

The first if may be exactly the right solution.

The second may be a coincidence.

But when the third appears, it's worth asking whether we're really dealing with exceptions or whether we've discovered that something we encoded as a rule should actually be data or configuration.

There's an opposite mistake too.

Building a generic abstraction when the first if appears can be just as expensive. We may end up designing a platform to solve problems that will never exist. So the goal isn't to always abstract. It's to recognize when the problem is no longer exceptional.

Questioning Doesn't Mean Changing

This distinction is fundamental.

When I ask why something works a certain way, I'm not saying it needs to be changed. Many times I've questioned a solution, we've analyzed it, and we've reached exactly the same conclusion:

it's fine as it is.

That's healthy.

If something works, doesn't create disproportionate costs, doesn't introduce significant risks, and still meets the needs of the business, changing it may be a terrible use of resources. The goal isn't to create a culture where everything is permanently under debate. The goal is to create a culture where decisions can be explained and questioned when necessary.

In another article, I explored a related question: how to determine when the cost of not changing begins to exceed the cost of change. Here I'm interested in something that comes before that calculation.

Knowing what decision we're evaluating and why it exists.

Reusability Doesn't Mean Designing for Every Possible Future

When I ask teams whether something could be made more reusable, I'm not suggesting that we build a platform capable of solving every problem that might appear over the next ten years. That would be another form of waste. The goal is to recognize when we already have enough information to know that certain conditions are likely to change.

There's an important difference between:

designing for every possible future

and

not unnecessarily closing off the future.

I'm much more interested in the second. A good technology decision doesn't need to anticipate everything that will happen. But it should try to avoid making an unnecessarily rigid choice that turns every future change into a rebuild.

Leadership Has to Be Questionable Too

Questioning has another consequence: sometimes we're wrong.

It's happened to me many times.

Being in a leadership position doesn't mean our questions are automatically better, nor does it mean we need to find something to change every time we review a solution. If, after discussing it, the team demonstrates that the decision makes sense, there's a perfectly valid response:

“You're right.”

If we want teams that can question decisions, the first person who needs to be willing to be questioned is the person leading them. Otherwise, we're not creating critical thinking. We're replacing one automatic answer:

“We've always done it this way.”

with another:

“We do it this way because the CTO said so.”

And we haven't improved anything.

AI May Make This Problem Even More Important

DORA has been studying how technical capabilities, processes, and culture affect software delivery performance since 2014. Its State of AI-assisted Software Development 2025, based on nearly 5,000 technology professionals, introduces an idea I find particularly interesting: AI acts as an amplifier.

It doesn't necessarily fix the system into which we introduce it. It amplifies what is already there. According to DORA, AI adoption among software development professionals reached 90% in 2025. The research found improvements in throughput, but also increased delivery instability.

That makes the discussion around inherited decisions even more relevant. Consider an extremely common instruction given to an AI-assisted development tool:

“Follow the existing patterns in this repository.”

That's a reasonable instruction.

But if nobody remembers why those patterns exist, we've just built an extraordinarily efficient tool for reproducing them. A decision that was previously copied by a few people can now propagate much faster.

AI can accelerate good practices.

It can also industrialize decisions nobody has revisited.

Strong Systems Don't Depend on Historical Answers

A strong technology organization isn't one that has always made the right decisions.

That's impossible.

It's one that retains the ability to explain why decisions were made, understand the assumptions supporting them, and revisit them when those assumptions are no longer valid.

So perhaps the problem with:

“We've always done it this way”

isn't that the decision is old.

The problem is that we lost the original and kept only the copy.

The next time someone asks:

“Why do we do it this way?”

I'd like us to be able to answer:

“We made this decision for these reasons. These conditions are still valid. If any of them change, we'll revisit it.”

We don't need to have every answer. But we should try to preserve the reasoning behind our decisions. Because building an organization capable of change starts with something fairly simple:

still knowing why we do what we do.

Sources and Further Reading