Shipping Technology in Mission-Critical Domains. What CTO Ryan Has Held Onto Across 20+ Years.

At Corpy & Co., where AI systems operate in real-world, high-risk environments, CTO Ryan Ginstrom leads with a simple principle: systems only matter if they work reliably in production and deliver measurable value. His approach combines strict engineering discipline, enforceable standards, and a focus on delivery. He treats reliability as something that must be designed, measured, and enforced. With over 20 years of engineering experience—including leading ML teams at Mercari—Ryan brings a rare combination of deep technical expertise and a grounded, people-first leadership philosophy. We sat down to talk about what drew him to Corpy, how he thinks about failure, and what kind of engineers thrive here.

Where failure satisfies no one — and could harm someone

ーーYou led ML teams at Mercari before joining Corpy. What's fundamentally different about the work here?

Mercari is a consumer-facing company, so all of our machine learning was pointed at consumers. At Corpy, our customers are businesses. But the goal of machine learning is still the same—to create value for customers. It solves some problems or adds some new benefits. That part hasn't changed.

What has changed is the weight of failure. At Mercari, a failure in my section might mean a query takes five extra seconds, or a result is slightly worse. It's an inconvenience. At Corpy, the consequences are much bigger. Equipment could be damaged. People's health could be in danger. We have a much greater responsibility not to fail. That responsibility changes how we build systems. We design for traceability: being able to answer what happened, why it happened, and how to fix it without guessing. Reliability isn’t just about preventing failure, it’s about making failure diagnosable and recoverable.

—— So, wanting to take on that level of responsibility was one reason you came to Corpy. Were there other reasons you chose Corpy?

There were two. The first is that the space Corpy operates in is incredibly important for the future of the world. ML is spreading into every corner of society, but there are still many domains where it can't be used because it lacks the necessary reliability and safety. If Corpy can achieve a breakthrough in safety and reliability, the range of places where ML can be deployed will expand dramatically. It's a uniquely exciting space to be in.

The second is that I thought I could contribute. Corpy has grown from a small company into a mid-sized one. I've spent my career at large companies working under rigorous engineering standards, so I believed I could bring that into Corpy's engineering culture and help build a more professional, reliable organization.

—— What do you mean, concretely, by "a more professional, reliable organization"?

My goal is to run engineering as an ROI-driven system. Every initiative has to have a clearly defined expected outcome — whether that's delivery speed, reliability, revenue, or something else. If you can't articulate the value, you shouldn't be doing it in the first place. This helps prevent a problem that engineering organizations commonly run into: over time, "effort" and "impact" start to drift apart.

Proving "it's not possible" is also a good result

ーーIn R&D, projects sometimes stall for reasons that have nothing to do with technology. What does that look like here?

There are a lot of reasons. A big one is that the customer changed their mind. They thought it would work one way, but once they see the solution take shape, they realize it's not what they wanted. Another is budget—our projects can run for years, and a customer's budget situation can shift.

We always keep in close touch with our customers. If their needs change, we adapt. This is especially common in machine learning, because our customers are very technical but usually don't have ML expertise. They might have a different idea of what machine learning can and can't do. So it's important to explain what's possible up front, and keep them updated as we go.

ーーSome projects stay at the PoC stage and never become long-term engagements. How do you see that?

Nobody knows whether a PoC is going to succeed—that's the whole idea of a proof of concept. We're working on the edge of technology, the very frontiers. Some of the things we're trying have never been done before. We won't start a PoC unless we think there's a possibility, but sometimes we discover the technology isn't mature enough, or the cost doesn't meet the customer's needs.

When a PoC doesn't continue, we don't consider it a failure. If we did a good PoC and proved that something isn't possible, that's also a good result. A PoC that proves something doesn’t work is still valuable, because it prevents us and the customer from investing in the wrong direction. In that sense, a clear “no” early is often a better outcome than an ambiguous “maybe” that drags on.

Engineers are smart, and they want to do a good job

ーーOver 20 years in engineering—what's a core belief that hasn't changed?

I have a core belief about engineers. One, they're all smart—nobody passes the hiring bar without being smart. And two, 99.9% of them want to do a good job. They want good results.

When you start every conversation with those two assumptions, things go a lot better. If somebody makes a mistake, you already know they're not dumb and they're not careless. So you ask: did they lack knowledge? Was there a breakdown in communication? You can throw out a lot of unproductive ideas and get to the real issue faster. In all my years, I've never met a dumb engineer, and I've never met one who didn't want to do a good job.

—— If that's your starting premise, it probably changes how you respond when mistakes or quality issues come up. But as an organization grows, you still need to align people around shared standards. How do you approach that?

Trust and systems aren't in tension. If anything, it's the opposite: it's precisely because I believe everyone is smart and wants to do good work that codifying standards matters. Making smart people guess at what "good work" looks like every time is a waste of their time, and handing people who want to do good work a vague definition of it is, frankly, unkind. So what we do is convert expectations into checks — something visible, measurable, and consistently applied. That way, engineers don't have to guess what good looks like, and we don't have to keep running manual reviews to hold the line on quality.

—— Do you ever find yourself disagreeing with engineers on your team? As CTO, what do you ultimately use as the basis for your decisions?

I try not to let my own preferences get in the way. If an engineer has a different idea than mine, I don't dismiss it. I look at it objectively—and if it's as good as my idea or better, I let the engineer choose. An engineer who's genuinely interested in what they're working on will do a better job.

If their choice is objectively worse, I talk it through with them. We go over the pros and cons together. And in my experience, when engineers see the evidence, they always say, "Okay, let's do it the other way." They want to do good work. But that trust goes both ways—they know that if their idea is a good one, I'll go with it.

Beyond fit, I also look at the bigger picture. How widely adopted is this technology? When was it last updated? How maintainable is it? How many people already know it? These things all matter.

—— Listening to you, it's clear you've developed a real philosophy around all of this. Is there anyone who shaped you as an engineer — someone who influenced how you think?

There was one person in particular, about ten years ago—a manager who really taught me about being a manager. He was an old veteran, started his career in the 1980s at Hewlett-Packard. He didn't know machine learning at all. But whenever I came to him with a problem, he would ask me questions. "What about this? What about that?" And by the end, somehow my problem was solved—I'd solved it myself. He always knew exactly the right questions to ask. I really respected that approach, and it shaped how I try to lead today.

Your job isn't done when you write the last line of code

ーーWhat's the one thing you always tell your team?

Customer focus. Customer value is the goal, but the way we get there is by shipping. Your job isn’t done when you write the last line of code, it’s done when the system is running in production and delivering value. Everything else—design, tooling, research—only matters if it moves that forward. If the customer isn't getting value, then what you did is useless—it only has purpose once it's creating value for someone.

This is personal for me. In machine learning, it's very common for work to never leave the lab, to never move past the experimentation stage. At Mercari, my team was the first to put machine learning into production, in front of actual customers. There were thirty ML engineers, and it was quite common for what they built to never reach a single user. I always felt that was a real missed opportunity. From the moment I started doing machine learning, I kept saying, "Let's get this in front of customers. Let's put it in the product." That's been my focus for well over ten years.

Curiosity is the price of admission

ーーWhat does Corpy's competitive edge look like in today's LLM-heavy market?

There are two angles. One is our traditional machine learning background. We can add functionality that pure LLM vendors can't. For example, many LLM systems include an OCR component, but we have deep experience with specialized OCR—reading diagrams, electrical circuits, things like that. We can layer that into an LLM system to make it stronger.

The other is our focus on reliability and explainability. It's a huge problem right now that LLM systems are stochastic—you can't ask the same question a hundred times and get the same answer. And when it gives a wrong answer, it's very hard to find out why. Because we focus on reliability and explainability, we can build much more robust, trustworthy systems. That was actually one of the main reasons I came to Corpy—there's a huge need for it, but not many people are doing it. Because it's hard.

ーーWhat kind of person thrives at Corpy?

Probably the most important thing is being curious. We do a lot of new things, and that's one of Corpy's real strengths. At Corpy, every project could be different. Different domains, different technologies. You're constantly learning, constantly staying on the leading edge. So being curious and enjoying new challenges is essential.

ーーAny final words for someone considering Corpy?

Corpy is a unique place to work. We work on leading-edge technologies. Our customers tend to be leaders in their own fields—in manufacturing, in research. And we're an international company working in Japan. Those things are quite rare. If you'd love to work in Japan, in a Japanese environment, but within an English-speaking engineering organization—working on cutting-edge tech with a lot of variety and a lot of excitement—then this is the place for you.