Paul Lewis has spent enough time around large technology programs to know how quickly a shining object can become expensive furniture. Mainframes, AS/400s, thousands of workloads, industrial systems, cloud platforms and now AI have all passed through his field of view. The machines change. The executive temptation does not: choose a fashionable tool, announce a transformation and wait for the organization to become transformed.
Lewis prefers a less theatrical beginning. Find the work that wastes time. Find the decision that arrives late. Find the customer friction everybody has learned to tolerate. Then ask whether technology can alter it in a way people will actually use. It is not the sort of advice that makes a demo sparkle, but it is the sort that gives a demo somewhere useful to go on Monday morning.
As chief technology officer of Pythian, a data and AI consultancy, Lewis leads technology strategy while helping customers connect cloud and data investments to business outcomes. He also works as an analyst at GigaOm, advises graduate programs at York University's Schulich School of Business, sits on the IT Media Group's advisory board and serves as a technical adviser to the board of Ontario's Workplace Safety and Insurance Board. His calendar offers him a panoramic view of the same argument from the classroom, the boardroom and the engine room.
Three windows on the same machine
Lewis describes his career in three broad acts. The first was roughly 17 years in enterprise IT, much of it in financial services. He has recalled an estate of about 5,000 workloads across 29 data centers, with billions of dollars of hardware, software and services passing through the decisions around him. His roles included senior technology work at Basi100, Filogix and Davis & Henderson. It was an education in constraints: regulation, existing systems, budgets, people and the inconvenient fact that no application lives alone.
The second act took him to Hitachi, where he encountered the physical consequences of software. Across about eight years at Hitachi Data Systems and Hitachi Vantara, culminating in the Global CTO role, the canvas expanded from traditional IT to operational technology. Manufacturing plants, transportation and large industrial environments turn an abstract architecture diagram into something with weight, noise and consequences. A bad data decision is awkward in an office. Beside a physical process, it can be rather more persuasive.
Pythian supplied the third window: cloud, data services and the rapid rise of enterprise AI. Lewis joined as CTO in March 2021 with a remit to steer technology strategy and help customers scale their data and cloud assets. The move did not erase what came before. It brought those earlier lessons into a market where executive enthusiasm can sprint several laps ahead of operational readiness.
There is a comic side to possessing this much history. When a podcast host introduced him as having more than 25 years of experience, Lewis corrected the number to more than 30, then complained that saying it aloud made him sound old. He has used mainframes and AS/400 systems; his public biography also calls him a “Million Miler.” Longevity has not made him nostalgic for old tools. It has made him suspicious of pretending any tool is permanent.
The pilot is not the product
Lewis divides the current AI conversation into three realities. Academic AI concerns machines that imitate capabilities such as language, perception, prediction and planning. Executive AI can look like a prompt box plus magic. Practical AI is the less photogenic combination: decades of mathematics, huge infrastructure, enterprise data, software engineering and governance assembled into a system that changes how work gets done.
This is why he argues that adoption is a more revealing metric than the number of pilots. A proof of concept can show that a model responds. It cannot show that employees trust it, that data reaches it safely, that its output fits a workflow or that anyone knows how to support it in production. Access to capable models is spreading. The advantage shifts to organizations that integrate those models into ordinary operations and measure what improves.
“The real challenge isn't just getting AI into production, but knowing how to support and evolve it once it's in production.”Paul Lewis
His preferred starting questions are almost stubbornly nontechnical. Where are employees losing time? Where are decisions delayed? Where do customers encounter friction? The answers form a prioritized list of opportunities. Only then does a team decide which data, model, agent or commercial feature belongs in the solution. The order matters. Starting with technology can produce a splendid answer to a question nobody was asking.
Find friction
Locate wasted time, delayed decisions and avoidable customer effort.
Prepare the ground
Connect governed, usable data to a clearly bounded workflow.
Operationalize
Plan ownership, monitoring, cost and support beyond the pilot.
Measure adoption
Track changed behavior and business value, not activity for its own sake.
Build doors into the architecture
The speed of AI has led Lewis to another principle: replaceability. Models improve, prices move, vendors revise products and yesterday's clever framework acquires the antique charm of a fax machine. He argues that pipelines, models, agents and workflows should be separated by clear contracts so any one piece can be swapped without breaking the rest.
Replaceability costs more at the beginning. Abstraction layers and disciplined interfaces are not free, and a tightly coupled prototype can reach the stage faster. The bargain changes once the system matters. If the original model becomes too costly, too slow or simply outclassed, a replaceable design turns panic into maintenance. The architecture acknowledges uncertainty instead of engraving a guess in marble.
The point is not indecision. A company still has to choose and ship. It simply should not confuse commitment to an outcome with lifelong fidelity to the mechanism. Lewis's own career makes the distinction vivid. He has crossed generations of computing without asking each new one to preserve the prestige of the last.
The code needs a voice
Lewis is equally direct about the human architecture around software. When Pythian built out a software engineering practice, he began with leadership he trusted: a colleague who had worked with him for 15 years and understood his expectations, paired with program-management capability. The team came after the purpose, the principles and the shape of the work were clear.
He describes a federated model in which a core engineering group can draw temporarily on specialists from customer practices. Developers participate in backlog priorities and architectural decisions, then present the value of their work to colleagues. Credit stays close to the hands that built the feature. Ownership becomes something people practice, not a slogan printed near the coffee machine.
“Don't be just a ‘code creator’, be a ‘code communicator’.”Paul Lewis
That phrase compresses much of his leadership philosophy. The technical artifact has to travel outside its creator's head. An architect must persuade an architecture review board. A developer must explain why a feature matters. A CTO must translate spend and technical maturity into growth, efficiency or some other outcome a CEO and CFO can recognize. Fluency in code opens one kind of door; fluency in consequence opens the next.
Lewis uses CTO ask-me-anything sessions to bring external observations, quarterly software outcomes and technology debates into the company. He has said that at least half of his LinkedIn engagement comes from people who hear those ideas and ask whether his team is hiring. Public thought leadership, in his case, became both a way to refine a point of view and a recruiting channel.
Measure what changed
Years before enterprise AI became the object in every shop window, Lewis was urging technology leaders to “start measuring outcomes not process.” The line survives because it is portable. Remote work, software delivery, cloud migration and AI adoption all generate abundant activity. Meetings happen. Tickets move. Models answer. The stubborn question remains: what became better?
His answer is not to dismiss process. Pythian's engineering work uses roadmaps, backlogs, standups, reviews and automation. Process is scaffolding. The building is the organizational purpose: more growth, less friction, improved decisions, a customer served with less effort. Confusing the two is how a busy technology department can become a very expensive weather system.
Lewis also keeps one eye beyond the current build. While a team delivers year one, leadership should prepare years three and four, negotiate the next investment and plan the transition from building a system to running it. This is where aspiration becomes operations. The future arrives as a budget, an owner, an interface and a support rota long before it arrives as a keynote.
His career does not offer a magic model for AI. It offers something more durable: a sequence. Begin with a human or business problem. Ground the system in data and governance. Give builders ownership and a voice. Measure adoption and changed outcomes. Leave enough doors in the architecture to carry today's machinery out when tomorrow's arrives. Then, when the shining object becomes furniture, at least someone remembered to measure the doorway.