Twenty years ago I crossed an ocean to become a rocket scientist. I had trained as an aerospace engineer, and my PhD in aerospace engineering at Rensselaer Polytechnic Institute was meant to be the next step toward building rockets.

My career took a different turn. I did not end up building rockets and for a long time I thought that story was closed.

And while my career trajectory changed, the things that have excited me throughout my career have always remained the same. I wanted to be close to complex engineering. I wanted to work with the newest technology on the hardest problems available, and I wanted the results to land somewhere I could see them, in a machine on a road or in the air.

Hold onto that long enough and your career starts to trace the shape of something larger than any one job. Over time, my career has traced the biggest generational shift in how hardware gets built. Coincidentally, it also brought me back to aerospace.

Simulate first, then make it smart

Over the last thirty years, hardware development has been transformed by one idea: simulate first. The first full-vehicle crash simulations were run in the mid-1980s, and through the 1990s core R&D teams across industry adopted simulation to cut the cost and duration of physical testing and validation. It worked. Development cycles compressed, expensive prototypes gave way to virtual ones, and products reached the market faster. Today simulation-first is standard practice across aerospace, automotive, heavy machinery, oil and gas, and nearly every industry where the end product is a physical machine. In many programs, the major design decisions are made from simulation results before any metal is cut.

Once that battle was won, the ambition changed. The question was no longer how to build the machine faster. It was how to make the machine smarter. Digital twins came first, keeping a living model of the machine connected to the real one. Then autonomous vehicles, machines that perceive and decide on their own. Now physical AI, which extends that ambition to robots and machines of every kind.

I have spent my career following that arc, trying to contribute at each stage. I started by developing simulation algorithms at ANSYS, writing computational fluid dynamics and finite element tools for engineers modeling systems that did not yet exist. From there I led digital twin work across energy, chemical processing, and automotive. Then I moved into the autonomous driving stack at Horizon Robotics and Applied Intuition, working on compute, perception, and the simulation and validation software that sat in the critical path of autonomy programs.

Moving closer to the machine

Something else was happening across those same years. I started in R&D, writing the algorithms. With each role I moved closer to deployment, to the point where the technology meets the machine and the team operating it.

That was deliberate. R&D work is satisfying, but the impact is indirect and it arrives late. Deployment is where you find out whether what you built was worth building. It is where software meets sensor noise, embedded constraints, production schedules, and engineers under real pressure. It is also where you learn what a customer is actually trying to accomplish, which is rarely identical to what they asked for.

The data kept getting heavier

Compare a hardware program today to one from fifteen years ago and the difference that matters most is data. Engineers generate far more of it during development. The machines generate more still once they are operating in the field. A single autonomous test vehicle can log terabytes in a day of driving. That gap between the data produced and the data that actually meaningfully contributes is widening every year.

Collecting, ingesting, and processing that data effectively has become a critical problem for every serious engineering team, and it is becoming a real differentiator. The teams that solve it iterate faster, build more robust machines, and make those machines smarter.

I have been working on some version of this problem for fifteen years. Only the shape of the data kept changing. First it was output from physics-based simulators. Then traditional sensor data during testing and operation: temperature, pressure, flow rate, vibration. Then much heavier perception data from radar, camera, and lidar, and that shift changed the job itself. You are no longer confirming that nominal operation looks nominal. You are searching enormous volumes of real-world data for the edge cases that will break the system.

Different domains, same underlying problem. Get the data from where it is produced to where the decision gets made, fast enough that the decision still matters.

Why Sift

Sift builds the tools and infrastructure that let engineering teams manage and process machine data effectively: ingest telemetry at scale, store it, search it, and turn it into decisions. That alone would be worth doing.

But what really convinced me is the promise of the platform. Sift connects the data flow across R&D, manufacturing, and operations. Those stages have historically run on separate systems, with separate teams and separate assumptions, and the gaps between them are where problems hide. Closing those gaps makes mission-critical machines safer and more robust, and it shortens the loop between what a team learns in the field and what they change in the next build.

Then there is the AI argument. In this era, data is the differentiator. Model capability follows from the coverage, quality, and accessibility of the data behind it, and that is more true for machines operating in the physical world than anywhere else. Whoever owns the data flow controls how smart the machine can become. Sift is building that infrastructure and common data layer for hardware companies.

And there is a bonus in it for me. Sift's roots are in aerospace, and much of our work is with the teams building rockets, spacecraft, and aircraft. I did not become a rocket scientist. But I get to spend my days working alongside the people who did, on the problem I am best equipped to help them solve. Twenty years on, that is close enough to my original ambition and I couldn’t be more excited.

What I am building here

My remit at Sift is deployment, and the goal is larger than deploying software.

I want our customer-facing team to earn trust through technical depth. When Sift is in the room, customers should feel that we are there to understand their system and help them solve the highest-value problem in front of them, not to sell, implement, and move on. You do not become essential by saying yes to every request. You become essential by understanding what a team is actually trying to accomplish and helping them get there.

The next generation of hardware companies needs infrastructure that matches the ambition of what they are building. That is the work I came here to do.

‍

Sift is hiring across deployment, engineering, and design. Check out the open positions.