Our CTO, Thamsanqa Moyo, hosted a tech leadership meetup at our Joburg office last month. He spoke about the Jem AI journey 30 minutes and took questions for an hour. Here is what he discussed, in his own words. Slightly edited for clarity and flow.
For as long as I have done this job, managing engineers has meant getting the most out of people
One-on-ones, OKRs, performance reviews. Processes like AGILE, tools like Linear and Jira, all pointed at human productivity. But as agents take on more of the engineering, the question I keep landing on is: how do you manage a team of agents?
I put three things on the table, each a reversal of something I used to believe.
We need to be more technical, not less
The path for an engineering manager has been to drift away from the code and towards the people. I think we have to turn that around. You cannot get less technical now. Managing agents means understanding deeply how they work.
There is an old idea in software that explains why: leaky abstractions. An abstraction hides complexity and works wonderfully, right up until it doesn’t. Then you have to understand what was underneath all along. AI abstracts away the difficulty of writing code, until something goes wrong.
I see the gap when we interview. A lot of engineers use coding agents every day, but very few understand concepts like sub-agents and skills, or even the difference between the two. So when something misbehaves, you hear people say the model is hallucinating, when the real issue is how they are using the tool.

Tools built for humans won’t work for agents
The kit that made human teams productive is not automatically right for agents. We started hitting rate limits on Linear, because agents work far faster than people. It is fantastic for human productivity. For our agents, it became a bottleneck in no time.
What I’m after is a single place agents know to read context from and write it back to, faster than a human could, instead of the fragments scattered across Linear, Notion and elsewhere today.
Several data stores underneath, with skills that tell the agents how to use it all, so they are singing from the same hymn sheet. We have started calling it the Jem brain. I want to be honest: it is less a hypothesis and more a work in progress.
Agents put more accountability on humans, not less
This is the reversal I find hardest to say out loud. We all carry management habits that more or less worked on humans. In an agentic world they get multiplied, and they stop working.
The obvious one is blaming the weakest engineer. I caught myself doing exactly that last month. WhatsApp went down, and WhatsApp is how our customers’ frontline workers reach us. The first thing I blamed was Mbali, one of our agents.
It had nothing to do with Mbali, or anyone on my team. It was an outage on Meta’s side.
Our monitoring told us something was wrong, but WhatsApp only published a notice once it had already resolved itself. So for under an hour we hunted for a cause inside a system that was working fine, because in my head the agent was the weakest link.
The agent does not care whether I scream or shout. A human can take ownership of a mistake. A junior engineer can accept blame and jump to fix the problem, and people will understand.
An agent? No. So the practices and habits that we leaned on in people-only teams is evaporating, and accountability is higher than ever despite engineers being further away from actual code than ever.
(To be clear, we have a strong feedback and ownership culture at Jem but shouting and pointing fingers at people is not how we operate. I’m just making a point)

You have to lean in long before things work perfectly
Someone asked what I would wish, six months from now, I had done differently today.
My honest answer is that I would regret not pushing hard enough on the things that don’t quite work yet. A year ago, audiences got defensive about whether AI could really do their jobs. The group in attendance here had long moved past that.
Simply adopting AI for coding no longer puts you ahead, it leaves you with the crowd. I want agents that can take a brief and deliver it into production safely, even for our biggest roadmap features.
That’s what we’re pushing for and it won’t happen if we rest on our laurels. We have to push for progress over perfection.

When it’s going well, knowledge starts flowing the other way
The part of the evening I keep coming back to had nothing to do with code.
At past events, non-technical people came to learn from engineers. This time it was colleagues from Jem’s Sales and Customer Success teams answering the engineers’ questions about AI.
It was incredibly validating, because it tells me we’re getting somewhere with this idea of becoming an AI-native company.
It also sharpens the big question I asked at the top of the session. If a non-technical person can manage an agent, and a technical person can too, what sets the two apart?
I think it is depth. The willingness to understand how the AI works, what to do when it breaks, and how to get the things that don’t work today working tomorrow.
What does that look like on a Monday morning? When an article references someone, I go and read that reference. If that points to another, I read that one too. Leaf to roots.
When Anthropic ships something, I follow the technology underneath it down through the labs’ own blogs, Substack and the better podcasts, never stopping at the first thing I hear.
That is the work now. Not letting the abstraction become an excuse to stop digging.
What brought us here won’t take us there.

