We spoke to Andrew Baker, Group CIO at Capitec, about AI, engineering leadership, and what happens when a 40-hour outage hands you a mandate to rewrite a bank's technology stack and move it to AWS. Andrew also writes about engineering leadership and banking technology on his blog, andrewbaker.ninja.
If you ask Andrew how he feels about AI, he won't pull out a strategy deck. Instead, he'll compare it to the mug on his desk.
"It's just a real thing, and it exists, and we are deeply embedded in using the technology everywhere to its maximum," he says. "It's not a strategy. It's not a wish. It is an absolute reality."
Andrew spent nearly a decade running algorithmic trading infrastructure at Barclays Capital in London, where every microsecond mattered. From there, he became CTO at Absa, before moving to AWS to work on EC2 engineering. Today, he is Group CIO at Capitec, after previously serving as its CTO.
At Capitec, he leads an engineering team of around 1,000 people supporting 26 million clients. At that scale, a failure affects far more than one team.
So when Capitec experienced a 40-hour outage just three months after Andrew joined, the answer wasn't simply to patch the problem. They rebuilt the system.
A 40-hour outage set the team on the path to AI
Before the outage, much of Capitec's estate was built around Windows and SQL Server in a more traditional architecture. Andrew's concern wasn't simply the technologies themselves, but a scaling model that looked very different from the distributed architectures used by hyperscale cloud providers.
The outage gave him a mandate to move the bank to AWS. He says he set up Capitec for AI years before it became a major industry trend.
That choice now guides how his teams use AI safely. He explains that you can't point an AI agent at a mainframe running COBOL, it would "tear it up." Capitec has about 600 PostgreSQL databases, each with a writer node for production and several read replicas. AI systems only access the replicas. Even if a model tried to change a record, it couldn't. As he puts it, the data plane is "agentically inert."
This difference matters, since most discussions about AI adoption focus on what the technology can do. Andrew, however, begins by thinking about what AI should never be allowed to do, and then plans from there.
He says, "AI adoption is really hard if it's something you think of now with an architecture from 20 years ago. But our architecture is designed for adoption."
"You still need teams. You still need diversity."
Before they rebuilt the bank's internet banking platform, which had about 400,000 lines of code built up over ten years, they assigned just one developer to the project with AI tools. They did it partly as a joke, just to see if it could work.
It turned out to be possible. He rewrote it in about three months.
The team was surprised by what came with that speed. "The good parts of that person came out in the product," Andrew says. "But it also magnified all facets of his personality. What he knew really well, he did unbelievably well. What he didn't know as well was problematic." The result looked almost ready for production, but it actually wasn't. Capitec had to bring in a team of six people with complementary skills to finish the job.
Andrew points out that this applies to every developer, including himself, and it's not a criticism of just one person. "I'm a backend developer. I write high-frequency trading algorithms. I don't write good front ends. I don't have the empathy. I don't care where the button is, what colour it is."
With AI, one person's skills can now show up at a scale that used to need a whole team. But the team's job of catching what one person might miss is still important. It just happens later, when the work already looks finished.
They tried a similar experiment with a payment system, but this time they added the developer to a full team much earlier, long before the code was close to production. "We saved that one," Andrew says.
The same logic, applied to people instead of code
Andrew built the data plane so mistakes never reach production. He believes companies should take the same approach with junior engineers: improve the environment so errors don't become disasters, rather than simply keeping inexperienced people away.
He challenges the common belief that companies should hire only senior engineers because juniors do more harm than good.
He uses a lift shaft as an analogy. If someone inexperienced falls and gets hurt, the solution isn't to ban young people from the building. It's to fix the lift. "If we need to shift our company to make it safe for a young person who's inexperienced to learn how to code, that's us," he says. "That's not them. That's our responsibility to do that."
This idea isn't just theoretical. OfferZen's 2026 Salary and Benefits Report found that 48% of tech leaders feel pressure to hire more senior engineers as teams get smaller, which is exactly the thinking Andrew's pushing back against.
His hiring approach follows the same logic. Traditional job descriptions often specify the exact shape of the person rather than the problems the organisation needs them to solve. Instead, he looks for people willing to tackle problems without clear instructions or examples. At Capitec's scale, much of the work is new and unprecedented.
His view on AI fluency is equally clear. It isn't a hiring requirement. "It's something you take for granted," he says, "like the ability to breathe." Anyone can learn to prompt a model in fifteen minutes. What matters more is the judgement to recognise when the output is wrong, because that skill can't be taught in fifteen minutes.
There is no single leadership principle
Good engineering leadership is rare, and Andrew has seen why firsthand. Across his career, he says he's worked with only two truly good engineering leaders. Too often, the problem was simple: people were put in charge of technology they didn't really understand.
He's not alone in that read. OfferZen's Engineering Leadership Report, based on a survey of 280+ South African tech leaders, found that 60% describe their own leadership growth as reactive or unstructured. As one CTO surveyed in the same report put it: "You can read all the books you want, but leadership only clicks when you start doing it, usually getting it wrong first."
When asked whether he has a single guiding principle for leadership, he rejects the idea entirely. "I don't believe one leadership principle should dominate every situation," he says. "It's 50 principles, and they all argue with each other."
So you weigh them up. You work through the trade-offs. You argue things out. And you teach, because in Andrew's experience, teaching is one of the best ways to learn yourself. "If you share knowledge, you'll receive a lot of knowledge," he says, "and it makes you a much better leader."
That might also explain his approach to AI. "AI doesn't eliminate engineering diversity," he says. "It makes monoculture more dangerous."
At Capitec, that's meant experimenting aggressively while building the systems, guardrails and infrastructure to contain what happens when one approach turns out to be wrong. Different viewpoints are the safety net. They're what stops a single misstep from becoming a collective stumble.
No crusades. No single answer. Just a carefully designed environment that can handle whatever comes next.