The Systems Engineer Mindset: Understand the Real Problem Before You Build

Years ago, I was working on a project for a company in the automotive sector that was building a new system with help from an external tech vendor. The system was supposed to make life easier for several departments. The problem was that every meeting about it, between the vendor and each department's management, happened without a single actual user of the system in the room.

I've always loved learning, so I started sitting in on these meetings, learning from them and with them, even though it wasn't really my job. One day, I was in the break room, and by coincidence, I found myself with that very department, the one I'd just heard discussed in the meeting. Except this time it was the employees themselves, not their managers.

And that was the shock: everything they told me was completely different from what I'd heard in the meeting.

I didn't stop at the shock. I got into a real conversation with them, asking how they actually worked, with no formal agenda at all. I gathered every real problem and the real way they worked, organized it clearly, and presented it to management and the vendor as a complete study.

The result was stranger than I expected. Management was about to impose an entirely new way of working on the department, but what they actually needed was their existing work, just organized and documented properly. The training they'd been expecting meant learning a whole new way of working. What actually happened was different: the new system really was built, but training on it was limited to using the tool itself, not a new way of working, because the system was built around how the department already worked. Everything was already familiar to them, and that saved a huge amount of time and effort in training.

From that moment on, I understood that my real job wasn't to build a system that works. My real job was to understand the actual problem and solve it in a way that makes people's work easier, not harder. If I hadn't verified the department's reality myself, the result would have been a new system forcing an unfamiliar way of working on them, instead of one that matched how they already worked and needed only simple training.

That became my rule from that day on: The goal of any solution is never the solution itself. Its goal is to make people's work easier and expand what they're capable of getting done. And you can't reach a solution that genuinely helps until you understand the problem at its real source, not from a report about it.

To this day, I remember a line every teacher repeated at exam time: "Understanding the question is half the answer." As a student, I saw it as a generic line, or honestly, a way for teachers to brush me off when I asked a question and didn't feel like explaining further. I never took it seriously.

Today, working entirely in tech, I actually understand that line, and I understand it's far more than exam advice. The same rule applies literally to any technical problem: understanding the problem is half the solution, and the other half is just execution once you've understood it correctly.

Before I Go On

Let me be honest: none of this is something I invented, even if my teacher said it years ago in his own words. It also has a formal name in the business world, Business Analysis or Requirements Engineering, with its own textbooks and standards written long before me. The difference is that I didn't learn it from a book. I learned it by accident, sitting in meetings I attended purely because I wanted to learn, and I understood it more deeply every time I applied it to a new problem, whether inside a company department, a specific project, or my own personal work. The principle doesn't care what kind of work you're doing. It cares whether you understood the real problem before trying to solve it, or built a solution on assumptions instead.

How to Actually Understand a Problem

Not every problem hands you a lucky break room moment like the one that exposed the gap for me, so I learned to create that moment on purpose. A formal meeting with whoever owns the project or the department, then an informal conversation with whoever actually does the work, no agenda, during a coffee break or any moment when people are relaxed and don't feel like they're in a formal setting.

Documentation Used to Be My Real Weak Point

Everything I gathered back then, I wrote down my own way, on paper and in personal notes. It worked, but it worked because I was the one who wrote it and the one who went back to it. If someone else had needed that same information without me, there was nothing organized for them to find. That's a second lesson I learned late: knowledge that can't be handed off to someone else is at risk of disappearing the moment you leave.

The Same Gap Keeps Showing Up

After that experience, I started noticing the same pattern in every technical problem I worked on afterward. The gap between what's said and what actually happens isn't unique to one department or one company. And the better I understood a problem, the lighter and easier the resulting solution was for the people using it.

At my current company, for example, I didn't start building any system until I'd seen how the department actually worked and asked them about their process. We have a department responsible for contracts and partnerships, and one of their heaviest tasks is logging each contract electronically in the system after signing. It's a task that eats up a huge amount of time and effort, especially with a large volume of contracts.

What we built was a very simple automation, using an AI model to read the contracts and upload the data straight to the database. It saved real time, effort, and cost. This example in particular confirmed something for me: the purpose of technology is to make things easier, not more complicated. Once you genuinely understand that, you'll excel at building systems.

Once you see the same pattern repeat more than once, you can build a single solution that serves multiple departments instead of a separate tool for each one. That's the difference between a system that grows with you and one that, two years later, turns into ten scattered tools nobody fully knows how to use. Later, that same principle grew into ARA Brain, a platform with seven interconnected systems. I verify each problem myself, look for the shared pattern, and build one solution instead of several disconnected ones.

Honestly, Not Everything Worked the First Time

Don't let any of this make you think everything succeeded on the first attempt. Back to the contracts example: when I first built the automation, the error rate was somewhat high, because some contract formats were hard to read, and the data wasn't reflected correctly in the system.

The fix I built was simple: every time a new contract is added, the system pulls a small random excerpt from it and sends it to the employee, so they can confirm it was uploaded correctly. That turned the employee's job from entering contracts from scratch into simply verifying uploaded data. The system didn't eliminate the employee's role, but it did lighten the load, and that's exactly the difference between a solution that makes something easier and one that just complicates the same thing behind a different technical interface.

What Did I Actually Learn From This?

If you ask me what mattered most out of all this, the answer isn't "talk to people." Every technical person already knows that in theory, even if they don't practice it. What I actually learned is that any solution you build is valued not for the technology inside it, but for how much it eases the work of the people using it. And you only get there if you understand their real problem properly, not from just a report.

So before you build your next solution, whatever the problem and whoever asked you for it, ask yourself two questions instead of one: did you actually understand the problem? And if you did, will the solution you're about to build genuinely make their work easier, or will it just give them something new to learn?