I'm an engineer. Everything else follows.
Marius Lupu — Debugging the Business of Technology or vice versa
The Origin
I started my career writing C and assembly for real-time embedded systems. Six years of 32-bit chips, preemptive threads, and the kind of concurrency puzzles where a single bug doesn't just crash your application, it bricks the hardware. You learn a very specific lesson in that world: *architecture is not optional*. Every abstraction layer must earn its place. Every design decision has consequences you can measure. Sloppiness is not forgiven by a reboot. Resources are scarce, so every single assembly instruction counts.
That discipline never left me. It became the lens through which I see everything—including things that have nothing to do with microcontrollers.
When I moved into management, I hit a wall. Three years of it. I initially assumed the job was about meetings, reports, and keeping people busy (I was spectacularly wrong about all three). The human complexity blindsided me, especially the leap from managing engineers to managing managers, where the feedback loops become indirect and the failure modes become political. I had no mentors for a long time. I had to debug the problem from first principles.
And then the insight landed: businesses are systems like any others, just with human beings as agents.
That sentence changed the trajectory of my career. Systems respond to engineering tools—you can model them, find their constraints, optimize their throughput. People require something fundamentally different: context, purpose, psychological safety, and room to grow. Mastering both, the mechanical and the human—became the work of the next two decades.
I learned to design teams the way I had designed products; to optimize organizational structures the way I had optimized code; to architect culture the way I had architected software platforms. Not as metaphor, but as method.
The engineering mindset (applied to everything).
Here is where I should probably warn you: I apply engineering thinking to *everything*. Organizations, strategy, bread baking, guitar tone, the layout of my woodworking shop. It's not a professional affectation—it's how my brain is wired. Understand the problem completely, model the constraints, design the solution, test it, iterate. Whether I'm troubleshooting why a development team can't ship or why my sourdough crumb is too dense, the diagnostic process is identical.
This obsession with doing things right—with *craftsmanship*—comes from a specific place: I hate fixing the same thing twice. My goal has always been what I call Zero Anxiety operations: systems so well-architected that they don't generate chronic stress. Not because they're perfect (nothing is), but because when they break, they break in predictable, diagnosable ways.
Here's the part most consultants skip: you must fix the mindset before you fix the machine. If you don't change how people view the system, no amount of re-architecting will hold. I take the harder path—fixing the root cause (the thinking) so we stop perpetually patching the symptoms (the code, the process, the "communication issues"). It's slower upfront. It's dramatically faster in the long run.
I'm also a compulsive cross-pollinator. I stitch knowledge from unrelated fields—music theory, evolutionary biology, photography, fermentation chemistry—because the patterns transfer. A sourdough starter is a complex adaptive system with feedback loops and environmental dependencies; so is a software team. The analogy isn't cute, it's *structurally accurate*. This habit of reaching across domains helps me see patterns others miss, though I'll be the first to admit: the human factor always increases complexity exponentially. Microcontrollers are predictable. People are not.
What you're actually getting (the spec sheet, not the brochure).
I believe in full disclosure. If I'm going to help you understand your system, you should understand mine first.
I am highly competitive and results-focused. In high-pressure execution modes, I can lose sight of the emotional landscape—my empathy takes a backseat to the objective. I've learned to catch this (mostly), but it's a design constraint, not a feature I can simply toggle off. Think of it as a processor that prioritizes throughput over latency: excellent for delivery, occasionally rough on the people in the pipeline.
I hate politics. Not the healthy "competing priorities" kind—the posturing kind, where decisions are made based on who's loudest rather than what's true. I function poorly in those environments. I function *brilliantly* in environments where people say what they mean, disagree openly, and resolve conflicts based on evidence rather than hierarchy.
I need closed-loop validation. I don't need praise; I need confirmation of signal receipt. I need to know the work is landing. I operate on trust and autonomy, but I need feedback loops to calibrate. A control system cannot operate without sensor data returning from the plant. So do I.
I am intellectually fearless but operationally cautious. I'll propose radical architectures, challenge sacred assumptions, and argue for approaches that make the room uncomfortable. But when it comes to *execution*, I want tested paths, safety nets, and rollback plans. I invent the bold engine, then I stress-test it until I can sleep at night. This is not a contradiction—it's a deliberate separation of concerns between design and deployment.
I am not a natural finisher of routine tasks. My energy goes into architecture, diagnosis, and the creative act of solving. The meticulous follow-through on repetitive operational detail? That's where I lean on the ownership of those around me. I've built systems to compensate (because of course I have), but if you need someone who thrives on checking boxes, I'm the wrong architect.
I frame all of this not as weakness, but as architecture. You wouldn't deploy a system without understanding its performance envelope. Consider this mine.
The structural engineer for designers.
I'm not a visionary. I don't wake up burning with a world-changing idea. I don't light up rooms with infectious enthusiasm (though I can hold one with a well-constructed argument and the occasional analogies).
What I am is the person who takes your vision and makes it buildable.
You provide the "Where" and "Why." I provide the "How" and "When." You dream the skyscraper; I draw the structural engineering plans that keep it from collapsing under its own ambition. I have the drive and capability to lead—but the pressure of being the *ultimate* decision-maker, the one with no backstop, creates more friction than value in my operating model. I'm most effective as the strategic partner who ensures the leader's vision doesn't crash into the wall of operational reality.
This isn't modesty. It's precision. The best systems have clear role separation, and I know exactly which component I am.
After twenty-plus years across three industries—automotive (where I learned safety-critical discipline), consumer electronics (where I navigated relentless B2C pace and B2B custom pressure), and publishing (where I drove modernization against the inertia of tradition)—I've navigated three corporate acquisitions from different vantage points. I've built standalone legal entities from scratch. I've worked with teams spanning Silicon Valley to Bangalore, within the compliance constraints of ISO, SoX, GDPR, CMMi, and SAFe.
The synthesis of all of it: technology organizations are systems where technical architecture, organizational structure, and business strategy must be deliberately designed to support each other. Conway's Law says systems mirror the organizations that build them. The reverse is equally true. When a company struggles to deliver, the root cause is almost never "bad developers"—it's an architecture mismatch between the code, the team structure, and what the business actually needs to achieve.
I'm the person who sees all three layers simultaneously and can operate at any altitude: deep enough to debate architectural patterns with your senior engineers, experienced enough to redesign your organizational operating system, strategic enough to ensure every technology decision traces directly to a business outcome.
The person behind the engineer.
I live in Iași, Romania, with my wife and son. When I'm not debugging organizations, I'm usually building something with my hands—which, if you've read this far, should surprise no one.
A few years back I started baking sourdough bread, which (predictably) led me down the rabbit hole of fermentation science. I now make everything from pickles to kombucha, and I understand the microbiology well enough to troubleshoot a sluggish starter the way I'd troubleshoot a sluggish deployment pipeline. When I needed a wood-fired oven for pizza—I built one. When I needed a cellar for steady temperature and humidity control—I built one. When I needed devices to smoke and cure meats—I built them. (I think you're getting the gist)
I'm setting up a proper woodworking shop, working with raw lumber, slowly accumulating the tools and the skill to build anything from a cutting board to a cabinet. Woodturning is next. There's something deeply satisfying about shaping material that pushes back—wood has grain, knots, tension. It forces you to work *with* the material rather than impose your will on it. (The organizational parallels write themselves, but I'll spare you.)
I ride cross-country mountain bike through the forests around Iași on weekends and run trails during the week. I'm a classic metalhead—Metallica, Iron Maiden, Judas Priest—but I listen broadly across the rock spectrum. I play acoustic and electric guitar (competently), fumble through keyboards (less competently), and even built a cajón (because buying one felt like cheating). Building an electric guitar from scratch remains on the to-do list.
I'm a technology early adopter by instinct, always experimenting with the latest tools and paradigms before they hit mainstream (the current AI wave has consumed a significant portion of my curiosity).
I also give back where I can. I speak at local tech and business events when asked. I sit on the board of a local NGO focused on community building and educational access, where my background helps shape project concepts in the early stages.
If you've made it this far, you now know more about how I operate than most people I've worked with for years. That's deliberate. I believe the best professional relationships start with clarity, not with a sales pitch.
If something resonated—if you recognized a way of thinking that matches how you want problems solved—then a conversation is the natural next step. No slide deck. No pitch. Just two people talking about a system that needs attention.