PhoenixDX sat down with Dr Steve Hodgkinson — former Chief Digital Officer at Victoria Police and CIO50 Hall of Fame inductee — to talk about why AI ambition without digital fitness so often falls over.
Steve: A lot of organisations are bringing a kind of suspension of reality to AI. They think they can launch AI initiatives without the organisational preparedness and mature capabilities to enable them. It happens with every new generation of technology — people think they can just give it a go without the training and preparation. It’s like waking up one morning and deciding to run a marathon because it’s a great ambition, without the training, discipline, and exercise regimes to actually have the fitness to do it.
Steve: Performative means doing it because there’s an expectation you should — everybody else is doing it and talking about it. The difference is whether you’re doing it in a way that’s foundationally enabled, sustainable and safe, and achieving a business outcome that justifies the effort and investment. In many cases, we’re seeing early-stage implementations that don’t satisfy those tests. The ambition is there, but the muscle is not.
Steve: There are three signs to watch for once something is implemented:
All of these point to immature adoption — a new technology that isn’t yet embedded in the organisation’s core application development frameworks and methods.
Steve: Put in place the disciplines and exercise regimes of digital fitness. That means bringing normal application development lifecycle concepts and mature foundational platform capabilities to AI. We take it for granted that any enterprise-grade application will be built on solid foundations, with reusable, standardised components and stringent cyber security and integration standards. The same disciplines need to be applied to AI projects as to any other.
Q. You’ve described “staccato thinking”, where every project starts cold. What do you mean by that?
Steve: With new technologies, people outside enterprise IT are empowered to give it a go because platforms are readily available through the cloud. If they have money and demand, they feel they can just go off and do it, often for the first time. That’s staccato thinking: each initiative is disconnected from the others and treated as a contained risk or opportunity. “Legato thinking”, to keep the music analogy, results in AI projects with flow. Each project becomes part of a well-exercised, robust pattern of activity, which is the normal context of enterprise IT.
Steve: I think of cadence as the most important indicator of digital fitness. A steady flow of relatively small, low-risk AI projects is much less risky than occasional large ones. The best way to give a board or chief executive confidence is for them to see it happening before their eyes — new applications dropping regularly, then evolving rapidly based on user feedback. The CIO’s defence is to exercise those digital muscles frequently. Otherwise, the board will tell you which project to execute, or someone in the business will take the lead without the experience.
Steve: ePINs was a conscious strategy to put a reusable application development platform in place. Previously, each system went through its own tender, with infrastructure selected to deliver only that system. Instead, we used the procurement to implement a platform — OutSystems — and then used it to deliver ePINs, with the explicit intent that it would be the first of many. They iterated it many times before full production, and the same platform, with its reusable components and microservices architecture, has since delivered other applications with less cost and effort.
Steve: AI is the latest evolution of these technologies, but it still needs to be connected, integrated and part of a robust, scalable, secure and governed approach. A platform like OutSystems creates the secure, reusable foundations within which AI functionality and agentic frameworks can operate. It’s much faster to build on inherited capabilities than to start from a fresh sheet of paper and then work out retrospectively how to hook it up to your legacy systems.
Q. Many CIOs are worried about how to control AI agents. How does a platform approach help with governance?
Steve: Take access rights and integration patterns. One way to govern them is through committees and rules. It’s so much easier if governance is applied mechanistically through the platform’s rule structure, so it happens automatically — you simply can’t breach governance in a platform engineered to prevent it. You don’t need to worry about your agents' access regimes if you can see exactly what access they’re granted and trust those controls will remain effective over time. The aim is an application governed by design and by engineering, not by committees making difficult decisions all the time.
Steve: Partly it’s about recognising the wide range of skills involved and choosing where to focus — partnering with vendors who specialise in parts of the lifecycle, rather than maintaining a full stack in-house. The other answer is cadence: a large number of small, repeatable initiatives, so you see what works, do more of it, and stop what doesn’t quickly. Meanwhile, much of the foundational engineering is being absorbed into the platforms, so skills are moving up the stack — into data engineering and design, application design, and more advanced cyber security and privacy design.
Steve: I’d start with three shifts in thinking:
Steve: It was an explicit part of the design. Frameworks, design patterns and playbooks were defined by PhoenixDX and OutSystems in collaboration with the in-house teams. Along the way, our people learned the platform and the playbooks, became capable developers themselves and went on to deliver other projects. There’s still an ongoing partnership with PhoenixDX, but it now works much more alongside in-house capability that’s intended to grow over time.