@jaona

About

I lead engineering where failure isn't an option and purpose is often lost. From low-level systems to large-scale delivery, I stay close to the code and the people; because engineering demands judgment, responsibility, and restraint. Not blind efficiency.

The background

I started my career where it matters most: close to the code.

I spent several years building and maintaining high-throughput, mission-critical distributed systems in C++. This experience shaped everything that followed. Once you have lived inside systems that cannot fail, you stop believing in shortcuts, slogans, and magical thinking.

Over time, my role expanded from software engineering to technical leadership, project management, and eventually large-scale delivery. Today, I lead complex engineering portfolios involving multiple & distributed teams, multi-million-euro budgets, and demanding clients. I am accountable for delivery, quality, cost, and schedule; and I take that accountability seriously.

But execution alone has never been enough for me.

The drive

I am deeply interested in what happens when technology, organizations, and humans collide. Engineering does not exist in a vacuum. Systems shape behavior. Metrics shape decisions. Tools quietly become constraints. I have seen well-intentioned teams drift into blind optimization, local efficiency destroying global sense, and delivery pressure eroding judgment. My work sits precisely at that intersection.

My management philosophy is simple, yet demanding: technology must remain understandable, accountable, and subordinate to human judgment.

As a leader, my role is not to maximize throughput at any cost. It is to create the conditions in which engineers can make sound decisions, understand the consequences of what they build, and remain responsible for it over time. Sometimes that means accelerating. Sometimes it means slowing down. It always means making trade-offs explicit instead of hiding them behind process or metrics.

The compass

I believe in delivery. I also believe that delivery without reflection is how systems become fragile, teams burn out, and organizations lose control of their own tools.

I stay deliberately close to the technical reality: architectures, constraints, failure modes, and people. Not out of nostalgia, but because distance is where abstraction turns dangerous. If I cannot understand a system well enough to explain it, challenge it, or stop it, then I should not be managing it.

Outside of work, I am a loving husband and father of two, a long-time piano player, an avid reader, and an inveterate tinkerer (from DIY projects to homelabs). These activities are not hobbies in opposition to my profession; they are continuations of it.

They keep my relationship with technology concrete, imperfect, and human.