As the engineering leader behind Xceptor's AI-powered Product Development Lifecycle (PDLC), Mike shares how his team moved beyond experimentation to build an engineering organization that delivers software faster while maintaining the governance, quality, and accountability demanded by financial services. Their conversation explores why AI transformation isn't about deploying more tools or building more agents—it's about solving real business problems, measuring outcomes instead of activity, and helping teams evolve alongside rapidly changing technology.
Much of the AI conversation today revolves around developer productivity metrics—more pull requests, more code generated, more AI agents deployed.
Mike argues that these metrics miss the point.
When Xceptor began introducing AI into its software delivery process, the team didn't define success by how much AI-generated code they produced. Instead, they focused on a single business outcome: reducing the time it took to deliver working software to customers. Every experiment, every workflow, and every new capability was measured against that goal.
Like many engineering organizations, Xceptor initially explored AI inside its product before expanding its use into software development.
Rather than chasing the latest trend or trying to automate everything at once, the team deliberately stepped back and identified one practical problem they knew AI could solve. Starting small allowed them to learn quickly, prove value early, and build confidence before expanding AI across the broader development lifecycle.
Working in financial services means every decision must be traceable, auditable, and accountable.
That doesn't change when AI enters the picture.
Mike explains why human oversight remains essential throughout the development lifecycle and how governance, quality standards, and measurable controls have become even more critical as AI accelerates software delivery. Faster development doesn't remove responsibility—it increases the need for thoughtful engineering practices.
As AI automates more of the repetitive work involved in software development, engineering roles begin to evolve.
Rather than spending time on implementation details, developers can focus on architecture, system design, customer challenges, and product thinking. Mike shares his vision of future engineering teams built around smaller, multidisciplinary cells where people work alongside AI to solve increasingly complex problems.
One of the most candid moments in the conversation comes when Mike discusses the human side of AI adoption.
Rapid technological change creates uncertainty for every engineering organization. As roles evolve and new capabilities emerge, many people naturally begin questioning what the future holds for their careers.
Mike believes leaders have a responsibility to acknowledge those concerns openly, bring people along on the journey, and create an environment where learning becomes part of the culture rather than something to fear.
Asked what advice he would give organizations just beginning their AI journey, Mike keeps it remarkably simple.
Start with a small, focused team.
Choose one problem with clear business value.
Set ambitious but measurable goals.
Most importantly, measure outcomes, not activity, and allow each experiment to inform the next.
For Xceptor, that iterative approach has helped transform AI from an emerging technology into a practical capability that's reshaping the way engineering teams build software.
Stay tuned for more conversations with technology leaders exploring how AI is changing software engineering, product development, and enterprise technology on CTO2CTO.
Host: Alex Lukashevich, Chief AI Officer at Forte Group
Guest: Mike Kinloch, SVP of Engineering at Xceptor
Lucas Hendrich: Welcome back to CTO to CTO, where technology leaders share real-world challenges, lessons, and insights from the front lines of innovation. I'm Lucas Hendrich, CTO at Forte Group. For this episode, I'm handing the mic to our Chief AI Officer, Alex Lukashevich, for a conversation with Mike Kinloch, SVP of Engineering at Xceptor.
Xceptor helps some of the world's leading capital markets firms — including global custodians, investment banks, and asset managers — automate mission-critical workflows across the trade lifecycle. Its platform combines AI, rules-based automation, governance, and human oversight to streamline processes like client onboarding, reconciliations, confirmations, and tax operations, helping teams move faster while reducing risk and maintaining control in highly regulated environments.
Alex and Mike explore Xceptor's AI journey, what it takes to introduce AI into software development, and how engineering teams can balance speed, innovation, and governance as the technology continues to evolve. Here's the conversation.
Alex: Hi, I'm Alex. We're here in Toronto, and I'm with Mike from Xceptor. Today we're going to talk about our exciting journey with AI in the product and in SDLC processes. Mike, tell us a bit more about Xceptor.
Mike: Sure. Xceptor is a data automation company. We provide a data automation platform to financial institutions, specializing in the capital markets space. We enable business users and non-technical users to automate manual processes within their organizations.
Our platform can extract data in any format, from any source, with any structure — structured, semi-structured, whatever it might be — and then map out the end-to-end process. The goal, of course, is straight-through processing of your data.
Xceptor runs the process once you configure it. If the process doesn't complete — maybe it didn't meet the validation rules, or the enrichments you set up aren't working to the specification you designed — those exceptions are logged in the platform. As a user, you're alerted and can go in and manage them. That's probably the simplest use case I could describe.
Alex: Complex as it is, I think I got it.
Mike: We provide a lot of richness in that space, and we take products to market on top of it: reconciliations, trade confirmations, tax, and so on.
Alex: When I hear taxes, banking, and ETL, it sounds regulated and controlled, which means the software you deliver has to check all the boxes.
Mike: Yes. The governance layer is probably the most important layer in Xceptor. If you work with highly regulated financial institutions, you need data lineage and traceability. Everything you do has to be audited, so you need full traceability. That's a really important layer for us.
I think governance and security are probably what our customers talk about most. Once you have that, everything on top becomes additional value.
Alex: Tell me about the journey from a traditional SDLC — where you fully control deployments, have traceability and requirements, and people sign off on what gets done — to using AI, which is unpredictable and non-deterministic, and removes humans. How did that even come up? You're in an industry that shouldn't be AI-first, if you will.
Mike: It's interesting, isn't it? From Xceptor's point of view, there are two ways to look at AI: AI in the product, and AI in or on the business. The AI PDLC — the AI-driven product development lifecycle — is really about AI in the business.
Most software companies have had real challenges executing the product development lifecycle over the years. Think about putting together requirements for a feature you want to deliver for a customer. Most companies find a lot of inconsistency in how those artifacts are put together. If you have poor requirements, everything down the chain is affected. To be honest, that's a real problem in almost every industry.
AI has really advanced over the last several years, especially in the last 12 to 24 months, and there's a lot of opportunity. It's quite exciting. The question is: How do you take challenges like artifact consistency, speed of delivery, and quality, and use AI to really improve them? That's where the thinking comes from. You have to figure out how to use the technology to your advantage, to drive the business forward, generate more revenue, and so on.
Alex: You mentioned the last 24 months, but AI has been around longer. Were you early adopters? Did you start playing with it in 2022, when OpenAI came out with GPT-3.5? Or did you wait for an external trigger, or validation from others in the industry, before deciding to try it?
Mike: We actually played with it more in the product at that point. We were very early adopters, trying to figure out how to use it in the product to solve real customer problems.
Thinking back a number of years, I found that quite challenging, because you had to build and train the models yourself. You were trying to apply them to a customer's use case while getting a high level of accuracy, consistency, or value. Training your own model is really hard. If you're a big enterprise like Meta or Google, you can throw billions of dollars at the problem and probably have a good chance of solving it. But even for them, in the early days, I didn't feel many great use cases came out of it.
They solved the typical ones, like call center work. Then even they started to struggle with how to broaden it, and we were in the same boat. We probably spent about 12 months on it and quickly learned we were never going to win that game. We needed to figure out how to use other providers' models or techniques to solve our customers' use cases, and how to integrate with them. Times have changed, and there's more flexibility now, but a few years ago that was the route we took.
Alex: So your first entry into AI was mostly about what you could do for customers. You weren't dogfooding it yourselves. You tried to build something for customers, and then decided to look internally: "Why don't we start building things for ourselves?" Is that how it went? How did the transition from product to PDLC happen?
Mike: We did have some success with basic models we built ourselves early on. Then Microsoft started releasing things like Document Intelligence, which made those models much easier to train, and we started getting real successes. The technology kept progressing, and the generalized LLMs became more and more powerful. We thought, "Hang on, these are actually getting pretty good. They're not perfect, but we can do a lot more with them now."
That's when the gate started to open. Maybe 24 months ago it still wasn't quite there, but we were playing with it more and could see it moving fast: "Maybe in three or six months it will be ready." Then all of a sudden — click — two or three months later things really accelerated, and the world opened up.
That's when it became, "We can really use these approaches to solve problems in the product and in the business through the AI PDLC." It gave us much more. We think of AI as non-deterministic, but we were actually getting more accuracy from it, which made it more viable to use.
Alex: You've been playing with this for a while, and at some point decided to go from product to PDLC. When you say "we," was there a group of enthusiasts, or one crazy person — say, someone named Mike — running around looking at every angle of where this technology could help? How did the idea start?
Mike: Initially, we were looking at how to use the concept of an AI agent. The industry went mad. It moved from AI models to AI agents: "We want to automate everything." At that point it was, "We have to figure out how to use agents." We did the same as everyone else. Then, after a few weeks, it was, "We need to step back. This is silly."
Everyone was figuring out what they could do with agents. You could see all the players in this space saying, "We have 500 agents." You look at that and think, "Really? What value are they actually adding?" It's also a really good marketing ploy: "We have all these agents; you should use our platform."
We looked at that and said, "Let's step back and not get dragged into the detail. What use case could we solve with this?"
Mike: That's when we reached out to you at Forte and said, "We want to build our first agent in the product. We play in the capital markets space, and we want to build a confirmations data extraction agent."
The challenge was that we receive, for example, emails with many different document formats attached and a lot of content in the email body. The content, the documents, and the document structures change all the time. We could handle that with Xceptor today, to an extent, by setting up lots of rules and templates. But it's really time-consuming, and customers don't want to do it. So we said, "Let's build an agent," and at that point we had the power to do it. That's where it started, and where our relationship started.
Alex: That's very true.
Mike: Then it moved to Mike, the crazy person, saying, "Hang on a minute. We need to revolutionize how our product development lifecycle works. We have to be able to move faster." I could see the benefits of the agent technologies, and how we could apply them to the way we work internally, not just to what we deliver for customers in the product. That's how it started, I think.
Alex: You mentioned something interesting: you had to step back and not follow the crowd with 500 or 600 agents, and focus on value. Was that reaction inherent because you've historically been customer-first — is it Xceptor's DNA? Or did you react that way because you saw others going for the count — how many cloud licenses, how many agents? Why did you look at it from a different angle than everyone else?
Mike: I think it is in our DNA. Dan, our founder, built the company from the ground up, and that's definitely how he tackled things: stepping back and solving something for a real, practical use case. It's also how I think. So as a team, and across Xceptor, it's in our DNA. As I said, we did fall into that trap briefly at the start of the AI period.
But look at other players, like RPA. Remember RPA? It was a massive thing. Blue Prism: "We've got a billion robots automating everything." Back then we probably had the same reaction people have now in the AI space: "They've got millions of robots. What are we going to do? Are they going to eat our lunch?"
You just have to say, "Hang on. Step back and think about the problem space. Treat this as an opportunity, not a threat." That's exactly what we did with AI. What's the opportunity here? How can we use it to our advantage? How can we prove something concrete really quickly? That's what everyone else was struggling with.
Alex: It was a tool in search of a problem.
Mike: A tool in search of a problem. People struggled to show a practical solution to a real problem, and I think that's what we're really good at, at Xceptor. We're good at zeroing in on a particular problem and saying, "We can solve this and build out from there." Not trying to build thousands of things, but a small number of things with a really big impact that deliver a lot of value.
Alex: You mentioned Dan, whom I've met, and I know you really well, so I can see why customer-first thinking wasn't a hard shift for you. But across Xceptor as an organization, was it a harder change for others on your team to operate in this new world? Not necessarily changing how they work, but changing how they deliver value, think about value, or think about deliverables, with AI as an accelerator?
Mike: I think we've been on a similar journey to most companies. Initially, it was just, "Give everyone the tools and let them use them." You're trying to figure out what will and won't work, and it's better to have everyone using the tools and learning than to restrict them. So we gave everyone the tools, didn't really track adoption, and said, "Go for it. Let's see what we learn," while encouraging people to share.
That slowly moved into the same DNA question: How do we solve particular problems with this technology? Bringing everyone on the journey at once is really hard. So think about the product development lifecycle. We build requirements, then features and user stories from them. Looking at their consistency, sometimes they were really good and sometimes really poor.
Could we use AI as a point solution to fix that? We focused on that, and got AI doing a really good job. From there, the point solutions quickly multiplied. I asked our head of UX, "Can you look at using it for user experience?" Our senior engineering manager: "How can we use it in the build?" QA: "How can we write automated tests?" A small group of people pulled that together.
We ended up with a bunch of point solutions being used, probably relatively uncontrolled, across teams. Some teams used all of them, some used a few. But we didn't give anyone a hard time. That's really when it accelerated into: How do we turn these point solutions into a proper, end-to-end agentic process?
Alex: Was that because you needed control or governance, or out of fear of uncontrolled AI running in production and potentially affecting customers? Was it an organic decision, or did you get there because it presented a risk?
Mike: AI gives us the opportunity to go faster. It also gives us the opportunity to add a governance layer around the quality and standards of the artifacts it produces throughout the lifecycle.
A human doing the same job day to day is human. They make mistakes, get tired, and miss things. That's not to say AI and agents don't get things wrong — they do. But to a degree, you get consistent output much of the time, and pretty good artifacts. Of course it's not deterministic. Sometimes the artifacts vary; ask it to create the same thing twice and you may get something slightly different. But the quality was really, really high.
Alex: Fair — if you know how to set it up properly.
Mike: Yes, so there was a layer of that. From a governance perspective, the way I thought about it was: if we're going to use AI to execute our AI PDLC, we have to have humans in the loop, first of all, because humans need to be accountable. Whatever happens, you can't make the AI accountable.
We also needed to track what was happening. A bit like the Xceptor platform, we need to track all the reasoning, track metrics, understand the problems and how it's performing, and lock it down from a security perspective. We've had to consider all of those governance aspects as we've built this out.
Alex: Here's an interesting question. When many companies build internal AI processes, they try to keep the work in-house. You did that, but you also reached out to partners and started working with us. Why? Did you want external expertise? Was your core team busy with other work? Tell me about the logic.
Mike: We're busy. We have lots of opportunities and a lot of roadmap to deliver. So part of it was: How do we do this while taking people on the journey, given we can't do it off the side of our desks?
The other part was bringing in someone like Forte, with AI experience, who could bring something to the table and a fresh perspective — thinking outside the box. And we took everyone on the journey as we went, using the internal team as stakeholders while shielding them. They have skin in the game and don't feel left out; we're taking them with us, but they don't need to spend 100% of their time on it.
Then we worked with Forte as a partner to figure out how to drive enablement over time, so we get more and more buy-in. So there were a couple of angles, and those two things made us bring in an external partner.
Alex: From our perspective, the fact that we were part of the team contributed too. We weren't there just to outsource a solution; we were there to solve the problem together. That's why it was such a good relationship — being in it together with you, training the trainers, and solving problems together. I think it went really well.
Alex: AI changes the way people work and think. Looking at where you are now versus when you started, what changes have your teams gone through? What's different about the team that's part of this AI journey? And is there a difference between the teams that worked with us and those that were more like observers?
Mike: It's interesting, and it varies across teams and personalities. As with any change in life, some people adapt immediately and find it exciting, others are more hesitant, and many are in the middle.
Because we're big problem-solvers at Xceptor, many of our senior engineers are quite excited about using AI to solve these problems, so getting them on board was pretty easy. They're problem-solvers, and that's the switch: moving from "We're using technology to do some work" to "How do we step back and use AI effectively, so we can start thinking about bigger challenges?"
There were some surprises across teams. Certain team members would say, "Yes, I'm using all these agents to execute tasks. They're fixing all my bugs, I'm reviewing them, and we're moving so much faster now." And I'd think, "Wow, nobody's talking about this." They're all doing it, but not communicating or sharing that knowledge, which is really strange. It's almost as if they're wrapped up in their own journey and get lost in it. "Can you share?"
So on one side, I'm driving AI forward with some senior people, and on the other, it's happening organically within teams, but people aren't really talking about it. They're finding their own paths. It's a strange mix.
Alex: It's interesting how team dynamics are changing. You said problem-solvers. I'm thinking about the team of the future. In the past, teams had roles and titles. I think that's becoming the past. We're transforming the technology and how we deliver, and teams will be transformed too. If you had a magic wand, what would your team of the future look like? How do you see Xceptor delivering software six months from now? Not the people, just the function of building things.
Mike: Let me start with the common concern: people worry AI will take their jobs. The way I think about it, AI is an accelerant.
I see the organization of the future as a cell structure. Instead of teams, you have cells of what I call product roles. The product person is still figuring out what to build, from ideation onward, working with AI to build out the requirements.
The builder role is about stepping back and becoming the problem-solver: not worrying so much about every detail, but thinking about the big challenges and using AI to orchestrate everything through the rest of the product development lifecycle — architecture artifacts, code, release notes, whatever it might be.
So for me, we need people to become problem-solvers. I actually see a world where the people we have become even more valuable, because they can step back and think about the big challenges. That's the difference.
Take the QA role, for example. It will move from someone who ticks boxes and checks that everything lines up, to someone who asks, "How do I use AI to provide a quality service to the different cells?" So QA isn't redundant; the way it operates changes. It's less about providing a service and more about enabling. It's no longer about checking all the boxes — the rest of the cell can do that with AI.
Alex: Interesting. I'm with you, because it opens up so many possibilities for individuals to play that builder role, whether they're building architecture, a test framework, or anything else.
Alex: What challenges do you foresee with AI, or with this model? What bothers you when you think about AI at Xceptor, or in development generally, six months from now? What keeps you up at night?
Mike: You're being abstracted further and further away from what you know. Mentally, that's really difficult.
One of the main things that keeps me up at night, more than anything, is the mental health of my team, and my own. I've spoken to my team about it, sometimes indirectly, and I try to be really transparent: "This is how I'm feeling right now." Sometimes I really struggle. I sit here and wonder what my role will look like in three or six months, because things are moving so fast. And I think everyone else is thinking the same thing; they're just not talking about it. For me, that's a massive challenge, above everything else.
It's crazy to think about. We can talk about technology and all these things, but that's the big concern for me. Everyone is sitting there wondering, "Am I going to have a job?"
You get articles — was it Standard Chartered, or someone, just today or yesterday — about shedding 80,000 people. You don't get all the detail behind it, because companies shed people all the time. But it reinforces the message and erodes people's mental health. That's one of the big challenges I foresee.
Mike: On top of that, there's a whole bunch of other things. You get more and more abstracted. How will these models advance, what else will come out alongside them, and how far abstracted will we get? How much will AI actually be able to do fully end-to-end, and how will we be able to trust it?
I have two hats on right now. One is the software engineering hat, which says, "This is super cool." The other says, "We work in financial services, with high degrees of regulation, and our customers need determinism." Something that fully automates a process end-to-end will probably be a real challenge for them. Internally, it may be fine for us as we build it out. But if we want to put something like that into our product, it suddenly becomes a really hard sell, at least today.
Alex: You raise a very good point. When people implement AI, they often think about the tooling, the team, and the product. But as you unpack it, there's the impact on customers and beyond — three or four degrees of separation.
Mike: And customers face the same challenges: How do I get AI into my company? How can I prove it works? They almost want it to be deterministic, which is hard. You need determinism, with AI as a layer on top that gives you the user experience to excel, while the deterministic layer sits underneath.
Alex: Compared to many other places, you're pretty far along the journey. Looking back — even though it's only been maybe six or eight months — is there anything you'd do differently, now that you know what you know? Would you start differently, pick different tools, try a different approach? What scars can you share?
Mike: It's interesting. What would I do differently? We moved pretty fast at Xceptor. You said a few months, but my time horizon is normally six weeks: do something, move.
I definitely would have involved more people earlier. I would have taken the senior management and executive team on the journey sooner. We're all still learning together. It's not about buy-in — I think we're really lucky at Xceptor that everyone is bought into how we need to operate, our processes, and how we think about customers, from the top down. That's fantastic. But I'd have created that clarity earlier. That's definitely something I'd do differently.
Alex: You're far ahead of many other places. We were at a conference where people asked how you got there. Say a company is just starting: they're focused on tooling and have just deployed a bunch of Claude licenses. They come to you and say, "Mike, I want to be where you are. What should I do?"
Mike: Build a dedicated team, however big or small. We talked about the Forte relationship, which has worked really well. I didn't want to distract our team, so I brought people in to work as part of our team.
Form that team early and find a very specific use case: not too complicated, something relatively simple that you think will add value. Then go at it. Run a hackathon very early — a couple of days, maybe a week — and thrash it out. You'll achieve a lot in a very short time, and it will bring real clarity about what these technologies can do. I think you'll be surprised how capable they are and how easy it is to solve some of these problems.
Mike: Once you have a team and have run that initial proof of concept, set yourself very small, incremental goals. The way I like to do it is, "We've got six weeks." Not "Let's plan some work and see how long it takes," but "We've got six weeks. What will we get done? Here's the outcome we want, and here's the North Star."
Ours was building connectors in a day. It used to take two weeks. "We want to build a connector in a day. We have six weeks. How do we make it happen?" That really sharpens the mind. You're not planning to fill a bucket of time; you're asking how best to hit the goal.
Mike: Then work out how to measure it effectively. You see a lot of "We generate loads more PRs now — look at our PR throughput." For me, measure the outcome. For us, the first thing we cared about was how fast we could go from writing a connector's requirements to getting it into a customer's hands.
Once we knew that was the main outcome, we could look at the measures beneath it. Efficiency: how fast can we move through each stage of the lifecycle? Quality: what do the artifacts look like? Cost: how much does it cost? And most important of all, user experience: what's it like for the people using it? Those were our four pillars.
By keeping it that simple, keeping everyone energized, and running sprints of three days or a week — really short periods — you start seeing value very quickly. Then you can pivot and adapt. Just get to an MVP really quickly. For me, that was the number one technique, and it's still the one we use going forward.
Alex: That's great advice. In full transparency, when our team first heard "a connector in one day," they started going crazy. About two weeks into the project, they said, "We can actually do that." Toward the end, they were saying, "Oh no, we should have done it in one day." They felt they could have squeezed it. We got it to two days.
Alex: For what it's worth, it's been a hell of a journey, and I'm happy we're partnering with you on it. I'm done with my questions. Is there anything I didn't ask that you think is worth mentioning? Otherwise, I'm all out.
Mike: I think we're good. We've covered a lot of ground.
Alex: Honestly, I appreciate it, man. Thank you.
Mike: It's a pleasure.
Lucas Hendrich: That's it for this episode. Join us next time for more real-world conversations between technology leaders. And if you liked what you heard, subscribe to CTO to CTO. See you soon.