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 found myself, by pure coincidence, with that very department, the one I'd just heard discussed in the meeting. Except this time it was the employees themselves, with none of their managers around.

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, when what they actually needed was their existing work, organized and documented properly. The department had been bracing for training on a whole new way of working. In the end the new system really was built, and training on it covered only the tool itself, because the system was built around how the department already worked. Everything in it was familiar to them, and that saved a huge amount of time and effort in training.

From that moment on, I understood what my job really was: understand the actual problem, then solve it in a way that makes people's work easier. Had I skipped verifying the department's reality myself, the result would have been a new system forcing an unfamiliar way of working on people whose existing way needed only organizing and 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've understood the problem at its real source.

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 finally get that line, and I get that it goes well beyond exams. 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.

None of This Is New

I should be clear that I didn't invent any of this, even if my teacher said it years ago in his own words. It 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 only in how it reached me. 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 kind of work makes no difference to the principle. What decides everything is whether you understood the real problem before trying to solve it, or built a solution on assumptions.

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 forget 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 only 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 kept finding the same pattern in every technical problem I worked on. The gap between what's said and what actually happens exists in every department and every company I've seen since. 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 and effort, and it cut costs. This example in particular settled something for me: technology exists to make things easier. Once you genuinely internalize 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 and look for the shared pattern. Then I build one solution.

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, who confirms 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 is the whole difference between a solution that makes something easier and one that hides the same complication behind a different technical interface.

The Lesson That Stuck

If you ask me what mattered most out of all this: every technical person already knows to talk to people, in theory at least, even if they rarely practice it. The lesson that stuck with me sits one level deeper. A solution is valued by how much it eases the work of the people using it, and the technology inside it comes second. You only get there by understanding their real problem properly, from them directly, and a report about their work doesn't count as understanding.

So before you build your next solution, whatever the problem and whoever asked for it, check two things. Did you actually understand the problem? And will what you're about to build genuinely make their work easier, or just give them something new to learn?