Decades inside the tech industry

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.

My bet at Redis was on Rust, in a product built mostly on C and Python, as part of an effort to modernize the codebase and make it more robust and performant. I rewrote a core component of the cluster software in Rust, and it was genuinely hard: Rust's async support was still half-built then, so I was on the nightly build, chasing libraries that shifted under me, on a component that couldn't fail. It held up, and that working precedent mattered: when the company later set out to rebuild its cluster manager from scratch, I wasn't on that team, but I was the one they asked which language to use, and I made the case for Rust over the alternatives and helped them get started. I'd also helped rewrite RedisJSON, Redis's JSON data type, from C into Rust from its first commit, years before AI made rewrites like that cheap.

I took over Redis's proxy team in April 2020, during the COVID lockdowns. It's the module tens of thousands of client connections pass through, the most performance-critical part of Redis. I inherited a team that had gone quiet: people did their job and said little else, with no real sense of team. I had to build trust as a brand-new manager, entirely over video calls. I rebuilt the culture from the ground up, and got the team measuring itself by what we delivered together. I also found us spending nearly all our time reactively fixing bugs, and pushed the team toward fixing the recurring problem areas instead, against real pressure from above to keep the bug count moving. The code got measurably more stable, and the work got more interesting. Later I led a second team, spanning Israel and Bulgaria, automating Redis's cloud operations across Kubernetes, AWS, and GCP.

I came to Enigma as a researcher and one of the founding engineers behind the Enigma protocol. My first task was explaining the Ethereum protocol to the rest of the engineering team, to get them fluent enough to build on it. Originally we built the core engine in C/C++, and then decided to rewrite it in Rust, while the language was still unstable enough that shipping with it was itself a bet. I was one of the people who pushed that bet through, understanding it deeply enough to carry the team with it: writing the procedural macros the new secret-contract layer needed myself, and doing the same for WebAssembly, which nobody else at the company understood yet either. A year in, I was presenting that work at a conference in Berlin.

By the time I became team lead — over three sub-teams spanning the computation engine, the peer-to-peer network, and DevOps — Enigma had no shared workflow at all: everyone built whatever they personally judged worth building, with no team goal pulling the pieces together. I brought in Agile methods. For the first time, the team worked toward a single shared goal. The harder part was building a culture where people across three very different disciplines felt safe enough to lead, and to disagree with each other, out loud.