Seven years at IBM split evenly between two very different jobs: engineering inside a shipping product, then formal-methods research — different people to answer to, different definitions of "done." Working both at once meant learning to hold two different definitions of good work in the same conversation, and switch between them on demand.

I came to IBM through my thesis — automatically generating Rhapsody statecharts from legacy code. That grew into something bigger: the Rhapsody Action Language, with a syntax simple enough for systems engineers who'd never coded, a parser, an AST, and automatic model generation. It had to work inside a product people already shipped, on models and customers it couldn't afford to break. It shipped, and it's still used in the field. What stayed with me was what it takes to carry a genuinely hard technical bet through years inside a live product, when month one gives you no proof it'll work.

I led IBM's part of RePhrase, an EU Horizon 2020 project building tools to help developers refactor data-intensive C++ applications for heterogeneous multicore and GPU systems. It meant presenting and defending IBM's work in front of international partners who had their own stakes in the outcome. Aligning a shared deliverable across institutions that don't report to you, or to each other, is its own kind of work, the same kind I now do between groups inside a company who each think differently. Our research group also had no organized process for testing or delivery, even though what we were building had real customers: typical of research work, where the theoretical part of the job is valued more than the practical one. I saw the gap because I'd come from years in industry, and I built a real CI/CD pipeline with Jenkins to close it.

I came to IBM to write Python, and soon after I joined, my team's manager left and I was handed the team instead. I hesitated over this choice, thinking I wanted to build, not manage, but took on the challenge. We owned the test platform behind XIV, IBM's high-end storage system: high-performance tools that hammered it on both the control and data paths and caught the esoteric bugs no off-the-shelf tool could find — a big part of why the system was so reliable. But what outlasted me was the platform other teams wrote their own tests on, and a Python course I started because much of the company still treated Python as just a scripting language, below real engineering rigor. I taught it across IBM's sites in Israel. Years later, people remembered me as the Python teacher more than as the engineer. The real payoff turned out to be in leveling people up.