Start with the why

In the 1950s, on a noisy factory floor in Japan, a machine came to a halt. It was a critical piece of Toyota’s production line — the kind of stoppage that could ripple through the entire plant. Workers rushed over. Managers frowned. The pressure was on: every minute lost meant money burned.

Most factories would have reacted like any sane human: patch it, restart, and pray it doesn’t break again.

But at Toyota, something different happened. An engineer didn’t just ask, “How do we fix this machine?”. He asked why it had failed in the first place.

Five questions. That’s all it took. Not five fixes. Not five frantic guesses. Just five whys.

By the time they reached the fifth why, the real problem wasn’t the fuse at all. It was a worn-out filter, neglected because maintenance routines weren’t properly followed. If they had stopped at the first answer — a blown fuse — they would have swapped it out, restarted the line, and waited for the next fuse to blow. And the cycle would repeat. But because someone kept asking why, they got to the root cause. They fixed the process, not just the symptom.

This became known inside Toyota as “The Five Whys”. It wasn’t just a technique. It was a mindset — a refusal to accept surface answers. A belief that real progress comes not from patching problems, but from digging until you understand the truth beneath them.

The results speak for themselves. Toyota transformed from a small, post-war carmaker into the most efficient auto manufacturer in the world. Their obsession with why turned into the Toyota Production System, which later evolved into Lean Manufacturing — a framework that reshaped industries.

The difference with other car makers wasn’t technical brilliance. Other car companies had smart engineers, too. The difference was that Toyota engineers were trained to flip the question. While most of the world defaulted to "how do we fix it fast?", Toyota asked "why did this happen at all?".

That single shift unlocked an entirely new way of working.

Better how makes good teams great — but it never turns the wrong problem into the right one.

Impactful engineers don’t stop at how. They push deeper. They ask why. And then they ask it again. And again. Until the problem is clear. Until the customer’s real need comes into focus.

To answer the why, you have to understand the business. Not superficially. Not by reading a mission statement. You have to understand the customers, the market, and the field you’re playing in.

Not every engineer dreams of reading balance sheets. Fair. But if you want your work to matter beyond code elegance, you can’t ignore the business behind it.

Consider the difference between a startup and an established enterprise. A startup has almost nothing but potential. No customers. No processes. No history to defend. In that context, asking “why” often leads to radically different answers than in a mature company.

The mantra “move fast and break things” exists for a reason: when you have nothing to lose, the biggest risk is in standing still. Fail fast, learn fast, iterate. That’s the startup way.

Now take an enterprise. They have products in the market. Thousands of customers. Brand reputation. Complex systems. Processes. Bureaucracy.

That “move fast and break things” mentality suddenly becomes reckless. You can’t iterate in the same way, because every break can erode trust or revenue. An enterprise must optimize differently. Their why is tied not just to growth, but to preservation. Their constraints are not just technical — they are business constraints.

Neither approach is smarter — they’re just optimized for a different game. The trick is knowing which game you’re playing.

The same logic applies inside a single company. A brand-new product that barely generates revenue will operate very differently from an established one that pays hundreds - or thousands - of salaries. The balance between risk and opportunity is fundamentally different.

Deploying a new feature on Friday afternoon might be fine — even desirable — for that new product you’re rapidly iterating on to win customers. But doing the same for a product with millions of users, a few hours before leaving it unattended for the weekend? That’s not bold. That’s reckless.

Understanding the business isn’t just about knowing the KPIs or quarterly targets. It’s about knowing the forces that shape the decisions your company makes, consciously or unconsciously.

Why do we prioritize this feature? Because it retains customers in a saturated market. Why do we invest in this process? Because a single outage could cost millions. Why do we favor stability over quick experimentation? Because the cost of breaking things is higher than the potential upside.

Your engineering decisions only have leverage when they are aligned with the business. Building faster code doesn’t matter if it doesn’t help the company survive or grow. Optimizing a service for scale doesn’t matter if the business is still figuring out what the product is. Shipping faster is meaningless if you risk losing millions in churned customers. You cannot separate the technical from the business, because they are intertwined in the real world.

Of course, sometimes the business’s why is wrong or outdated – markets shift, strategies drift. That’s when understanding the business helps you challenge it intelligently, not just follow orders faster.

Understanding the business doesn’t make engineering easier — it makes it smarter. It gives your why purpose and your how direction. Without it, you’re just a coder executing tickets, a solver of arbitrary puzzles. With it, you’re an engineer who shapes outcomes, who drives impact. You’re no longer asking how to build — you’re asking how to make a difference.

Because you can be the most skilled engineer on earth, you can build the fastest, most elegant systems in the world. You can ship perfect code, deploy with zero downtime, and optimize endlessly. But if your engineering isn’t aligned with the business, it’s invisible. It’s wasted energy. And nothing kills an engineer’s potential faster than brilliant work that nobody needs.

Have you ever seen a new engineer join the team and immediately start declaring everything broken? “The architecture is a mess". “The API is inconsistent”. “This module looks like spaghetti — I could rewrite it in a week”.

It’s almost a ritual at this point. Fresh eyes, sharp mind, full of confidence — ready to fix the world in five business days. And honestly? I love that energy. That curiosity, that refusal to accept “because it’s always been that way” is fuel for progress.

However, the reality underneath that “mess” is far more complex. That code wasn’t written by idiots. It was written by dozens of smart engineers — some probably better than you — over years of iteration, customer requests, bug fixes, late nights, and product pivots.

That weirdly shaped method signature? It exists because of a nasty production bug three years ago, fixed on a Saturday night at 3 a.m. That “inconsistent” API? It’s a deliberate compromise to avoid breaking thousands of integrations.

The product you see today isn’t a clean implementation of a perfect design. It’s a living organism that evolved under pressure — through survival, not symmetry. Every part of it reflects trade-offs between speed and stability, deadlines and debt, customer happiness and engineering elegance. Or, as Grafana’s old-timer Carl once told me, “Survivors are winners”.

Understanding the business is a good start. But to truly make an impact, you need to understand the product as well — its architecture, its history, and its trade-offs.

Before you challenge a decision, make sure you understand why that decision was made. And once you do, then challenge it. That’s how evolution happens. Because sometimes, the “mess” is right. Sometimes, the ugly solution is the one that keeps the business alive — not the one that wins architecture awards.

Understanding the product doesn’t mean accepting it as is. It means seeing the full picture before changing it — so that your improvements are real improvements, not well-intentioned regressions.

So, like asking why in business, asking why in the product is just as important.

At this point, you may be thinking: “Cool — but what does that mean in practice? How do I actually learn about the business and the product?” Here are a few strategies that I’ve found incredibly effective over the years.