We all agree that the role of the technology leader is being rewritten in real time, and if you’re building the systems they depend on, you need to understand what they’re asking for now. Let me be honest about something. For most of my career, the conversations I had with CIOs followed a pretty predictable script. They’d describe a pain point, I’d map it to a solution and we’d talk timelines and integration. Clean. Transactional. Technical. Very straightforward, right? That script has been shredded. Over the past couple of years, working across public sector agencies, global enterprises and mid-market companies in Latin America and now the US, I’ve watched the CIO role transform in a way that genuinely changes how I do my job as a solutions architect. The technology leader who used to care primarily about uptime and cost efficiency now walks into conversations asking about competitive differentiation, cultural change and workforce transformation. And they’re right to ask. The shift isn’t cosmetic. It’s structural. The problem hiding in plain sight Here’s what I kept seeing in failed modernization projects, and I saw a lot of them: The technology worked fine. The architecture was sound. The implementation was clean. And the project still stalled or quietly died six months in. The root cause was seldom technical. It was a decision-making problem upstream of delivery. Strategy that hadn’t been translated into clear operating priorities. Conflicting stakeholder mandates that nobody had formally resolved. Organizational structures that pull in different directions from the infrastructure teams trying to serve them. What I’ve come to think of as “decision integrity”, the discipline of making sure strategy connects to execution, was missing. And the CIO, historically, wasn’t positioned to own that gap. They were downstream of it. That’s changed. The CIOs I work with now are increasingly the ones driving that upstream clarity. They’re defining outcome frameworks, arbitrating tradeoffs and forcing the organizational alignment that makes technical delivery land. The architecture conversation I have with them today is as much about governance and organizational design as it is about platforms. What this means if you’re building for them From where I sit, designing solutions around open-source platforms, hybrid cloud and AI infrastructure, the practical consequence is this: The technology decisions my customers make are no longer primarily about technology. A CIO investing in AI-ready infrastructure isn’t just buying a faster platform. They’re making a strategic bet that the organization can operate differently at scale. Which means the infrastructure must support not just the technical requirements, consistent data access, automated policy enforcement and visibility across hybrid environments, but also the organizational ones. Can non-technical stakeholders trust the system? Can the governance model hold up as scope expands? Can the platform absorb the messiness of real enterprise change without the whole thing collapsing? Technical debt is where this gets painfully concrete. I’ve seen environments where 30–40% of engineering capacity is absorbed by legacy maintenance. Not because anyone made a bad choice, but because previous decisions compounded over time without a deliberate modernization strategy. When a CIO tells me they want to move fast on AI adoption, the first conversation we must have is about what’s sitting underneath that ambition. You can’t build a reliable AI pipeline on top of infrastructure you don’t trust. The CIOs who are winning right now are the ones who dealt with that debt proactively not by declaring a big-bang rewrite, but by systematically creating the conditions where innovation can happen without adding to the entropy. That’s what I try to help architect. The cultural piece is the hardest part, and it’s real I’ll be straight here: When someone says, “cultural transformation,” my instinct is usually to translate it into something more concrete I can design for. Agile delivery models. Feedback loops. Automation that removes friction from the right places. That’s still my instinct. However, I’ve had to sit with the fact that the cultural piece isn’t just a soft addendum to the technical work. It’s load-bearing. Here’s the version I’ve watched play out more than once: You build a genuinely excellent automation platform. The tooling is solid. The pipelines work. And then adoption stalls because the teams who are supposed to use it don’t trust it, weren’t involved in defining it or are quietly protecting workflows that the new system would disrupt. The problem isn’t the platform. The problem is that nobody built the social infrastructure around it. Gartner’s projection that 25% of IT work will be handled autonomously by AI by 2030 isn’t a threat or a promise; it’s a design constraint. If you’re architecting systems today, you have to ask: What does the human role look like in this workflow once AI is doing the routine work? What skills are you developing in the team? Where does judgment still belong to a person? Those aren’t questions with clean technical answers. But they’re questions an architect must have an opinion on. Both hands on the wheel There’s a framing I keep coming back to, which describes the modern technology leader as both the navigator on the bridge and the engineer in the engine room at the same time. That’s exactly the tension I recognize from the field. The CIOs I most want to work with are the ones who haven’t abandoned either role. They’re genuinely curious about how the infrastructure works, not just what it delivers. And they’re genuinely accountable for business outcomes, not just technical ones. That dual orientation is rare, and it’s valuable and when I find it, those tend to be the engagements where we build something worth building. And this is one thing that fascinates me about open source: The people who engage with it tend to be true tech experts. For those of us on the architecture side, the implication is clear. We can’t show up to these conversations as purely technical resources anymore, either. The best solution I can design is useless if it doesn’t connect to the organizational reality my customer is operating in. Understanding the strategic pressure they’re under, the cultural conditions they’re working with, the decision-making constraints they’re navigating, that context shapes everything about how I recommend we build. The engine room and the bridge have always been part of the same ship. It just took a while for the org charts to catch up. This article is published as part of the Foundry Expert Contributor Network. Want to join?