An Interview with...
ERIC ASHMAN
A lot of my work has come through relationships, referrals, and long-running conversations with people trying to build something difficult. That is still how most of it happens.
For most of my career, people have known me as a software and systems leader. What has changed lately is that more of the work has been landing at the intersection of infrastructure, operations, and AI-ready platforms.
So here is a short fictional interview with "Modern Technologist" magazine about how I think about the work now.
MT: How do you introduce yourself now?
EA: I would describe myself as a technology leader who works across software, systems, infrastructure, and delivery. Recently, more of that has involved AI infrastructure and the operational side of modern platforms, but it feels like a natural extension of the same work I have been doing for years.
MT: What changed?
EA: AI pushed infrastructure back into the foreground. For a long time, a lot of companies could abstract away the physical and operational realities of compute. AI changes that. Latency, data location, capacity planning, governance, and reliability all matter more again, so infrastructure becomes a much more strategic conversation.
MT: Where do Flexnode and Apex Foundry fit into that story?
EA: Flexnode pushed me deeper into modular digital infrastructure and the systems needed to operate it well. Apex Foundry carries that further into enterprise AI infrastructure and the operating questions around it, especially where control, governance, and discipline really matter.
MT: Why does control over infrastructure matter to you?
EA: Because a lot of organizations do not just need access to technology. They need to know where data lives, who can access it, how systems fail, how they are governed, and what the long-term operating model looks like. That has always mattered. AI just brings those questions to the surface faster.
MT: Why keep software engineering prominent on your site?
EA: Because software is one of the main ways you make infrastructure useful. Good operations need control surfaces, integration layers, telemetry, deployment systems, and internal tools. I have never really seen software engineering and infrastructure as separate camps. They feed each other.
MT: What is your bias when you walk into a new project?
EA: I want to get to the truth quickly. What is real demand and what is theater? Which constraints are hard and which ones are just assumed? What needs to be built now, and what can wait? I like ambitious systems, but I respect operating reality. A beautiful architecture that nobody can deploy, support, or pay for is not much use.
MT: How does your earlier systems experience show up in the work now?
EA: All the time. I came up in an era when you bought servers, racked them, wired them, monitored them, and fixed them when they broke. That gives you a healthy respect for failure domains and operational ownership. It also keeps you honest about the difference between a demo and a system that really has to run.
MT: What do you look for when building teams?
EA: Curiosity, range, and honesty. I like people who can go deep in their specialty and also care about how the adjacent layers work. The best teams are not built from people who hide behind narrow ownership. They are built from people who want to understand why the whole machine behaves the way it does.
MT: What kind of problems are most interesting to you now?
EA: Problems where infrastructure is strategic, not incidental. That includes AI deployments, but also broader platform and operations problems where architecture, reliability, and technical judgment really change the business outcome.
MT: What should someone expect if they work with you?
EA: Directness, clarity, and hands-on problem solving. I like strategy, but I do not hide in it. I want to understand the details, surface the real tradeoffs, and get systems into a condition where they can actually run. That applies whether the work is software, infrastructure, or the increasingly common blend of both.