Jesutomiwa Salam is a backend-focused software engineer and systems thinker whose work spans fintech, health-tech, and blockchain-enabled products across Africa. Known for thriving in high-pressure, ambiguous environments, he has built and scaled systems that prioritise clarity, resilience, and trust—often under real-world constraints such as unreliable infrastructure and evolving regulatory demands. His journey into tech was shaped by self-directed learning, limited resources, and a deep curiosity about how complex systems work beneath the surface.
Across roles at companies like Curacel and Patricia, Jesutomiwa has led critical architectural decisions—from building flexible reconciliation engines to abstracting blockchain complexity for everyday merchants. Beyond code, he is intentional about leadership, mentorship, and creating environments where engineers are empowered to think independently while remaining accountable. His perspective reflects a growing shift in African engineering leadership: one that values adaptability, thoughtful trade-offs, and long-term system integrity over short-term optimisation.
In this exclusive conversation, Jesutomiwa reflects on learning software in isolation, how backend engineering reshaped his understanding of scale, and why clarity sits at the core of sustainable system design. He shares how African market realities influence architectural choices, what it takes to lead engineering teams through uncertainty, and why recognising quiet engineers is essential to building high-performing teams—offering rare insight into the mindset behind systems built to last.
You’ve described yourself as someone who learned software “majorly by doing.” Take us back—what was the moment you realised tech could be more than curiosity for you?
I think the first time it really clicked for me how much power I could wield with technology was when I started learning backend development (particularly how to insert entries into databases, update them, delete them, etc.). It was really interesting to me because I started to notice the same pattern on any website I visited: I would scroll on Facebook, create a post, and then realise that the app simply adds an entry to a database. That unlocked for me the idea that I could actually really build truly ground-breaking stuff with this technology. Frontend development gave me an appreciation for aesthetics, but I still felt like I was missing something. Learning how the backend works was when I realised I could really deploy my problem-solving skills into this new craft I was learning.
Growing up with limited internet access and no strong tech community, what did learning in isolation teach you that structured environments often don’t?
That’s a good question. I think there’s a sense of agency you pick up when you learn things in isolation that you can’t necessarily have in a more structured environment. I learnt how to build intrinsic motivation and seek the resources I need to get things done, because I realized it was all up to me; I genuinely think there’s a sense of ownership that I have, that only came about from the fact that no one prodded me to learn; and I think that ownership generally shows in the way I approach my work. I tend to be more self-driven and always seek solutions to my own problems rather than waiting on others for direction.
That first production system you built for your parents’ school—what lessons from that experience still influence how you architect systems today?
Oh, I learnt so many lessons from that project, but I would say one of the key ones was building reusable components for systems. I recall when I started building the application, I unnecessarily duplicated a lot of things (pages, logic, designs, etc.). It became so burdensome at some point that I began to ask myself if this was why software developers always have tired eyes (I would later learn that that was for an entirely different reason, lol); however, I recall reading a blog where I saw the writer using separate files to keep track of reusable style classes and components. I decided to try that out, and it just made the work a whole lot easier. I started using the same thought pattern for architecting any kind of system: I look for reusable parts of the system and try to abstract them well enough so they can be used/extended where needed.
You’re known for thriving in technically ambiguous, high-pressure environments. How do you approach decision-making when there’s no clear “right” answer?
I have two philosophies that guide how I make engineering-related decisions: the first is that there’s rarely a “right answer” when it comes to building and architecting software; it’s more of a set of trade-offs considered before building. What this means is I tend to start by imagining the worst-case scenarios associated with a decision, and deciding whether those scenarios are “worth it” or whether there are at least systems in place to cater for them. I find that this helps a lot in eliminating unnecessary overthinking; the moment you accept that there are really no right answers, it’s easier to live with decisions, knowing that you’ve considered the worst-case scenarios.
The second philosophy I have is that software is a living product that is subject to constant change; this frees me from the burden of thinking I have to have everything figured out immediately at any one point. It makes me rather inclined to make flexible decisions that are prone to being extended over time.
When designing systems meant to handle scale and complexity, what do you optimise for first: speed, resilience, or clarity—and why?
I would say clarity is the most important factor for me when I’m designing a very complex system. I’ve always regarded myself as a clean code advocate; I believe that any complex system starts with having clearly defined principles, component and structure; everything else flows from that point on, and so I try to think early on about how to decouple the different parts of the system, and make their responsibilities as clear as possible. A good thing this achieves is that it makes it super easy for other people to build on the system; an added benefit is that it makes it easy to optimise for the other two things (speed and resilience). For example, it’s hard to identify pain points in a system where every component is intertwined and bundled together; however, it’s easier when the system is well structured.
How do you balance theoretical “clean architecture” with the messy constraints of real-world African fintech and health-tech environments?
I try to think that one of the real measures of an engineer’s experience is how well they can transform messy, real-world processes into working code. I personally don’t think “clean architecture” is a theoretical notion; in fact, I would say that most people perhaps confuse “clean architecture” with “perfect architecture”. Software architecture, in itself, can’t exactly be perfect, and the reason is simple: software systems are living products; they change over time based on new constraints and new demands, which makes it almost impossible to have perfect architectures. However, clean architectures are always achievable; a clean architecture simply means a well-thought-out structure that accounts for current constraints while remaining flexible enough to accommodate future constraints. I try to enforce this also by working with engineers.
What were the hardest architectural problems you had to solve to make reconciliation reliable at that scale at Curacel?
Oh, there was a whole lot, but I would say a major problem at the time was finding a way to extend the reconciliation feature to a wide variety of users and businesses without constraining them to a particular file format or the expectations we had. The reason for this was that many customers had already worked with some of the existing reconciliation systems and didn’t want to change much to port to our better-designed system.
I saw this as a good problem; especially considering that other approaches to solving it involved trying to account for all possible formats (which ends up being an exhaustive process); I decided to go a different route entirely, and build a fast, efficient machine learning system that could infer the different file formats, and then find a way to map them to our existing standards, while also considering validation constraints. I consider this one of those problems that required thinking outside the usual “fintech-engineer” box and acting like a machine learning engineer.
At Patricia, you worked on stabilising crypto volatility for merchants who never interact with blockchain directly. What does that experience teach about abstraction and user trust?
I learnt quite a lot from that experience. One major thing I learnt was that one of the easiest ways to build user trust is to reduce the cognitive load of using your system. At the time, many businesses had no idea what the blockchain was; they were already using other popular Fintech applications to accept payments in fiat. Considering this, a key goal was to help users “feel at home” with a blockchain product. Other products at the time tried too hard to almost force the users to have to learn blockchain terminologies in order to use the application, but I decided it made sense to go a different route, and instead make the users feel there were using just another Fintech product, but with a different payment processor; especially considering the fact that the blockchain was just a means to an end for most of them. This proved to be one of the things that made the product stand out in the market; it was easier for users to trust a system they were more familiar with than one that seemed strange to them.
You’re intentional about recognising “quiet engineers.” Why is this important, and how does it change team performance?
I think one of the reasons I found this really important is that we engineers are, by nature, introverts: we like to put our heads down, get the work done, and call it a day. Engineering is filled with brilliant people who work all day behind the scenes to build beautiful things that everyone uses. Being a “quiet engineer” myself, I realised that one of the reasons my career has taken the trajectory it has is that I’ve had good leads and managers who made my work more obvious to people on the outside. It’s why I love doing this, I think I owe it to other engineers like me to ensure people know their value, and the value of the work they do; I also think it helps these engineers build the confidence to build even bigger things, and to also mentor younger engineers who like and appreciate their work, which often leads to a good team dynamic, especially in teams where there’s a mix of senior and junior engineers.
How do you give engineers autonomy without sacrificing accountability?
Good question. I like to think accountability is easier when the setting is as informal as possible, especially for more junior engineers. I find that senior engineers rarely have an issue with communicating as much as possible when given autonomy; however it’s an issue that occurs with juniors, and one way I solve this is to encourage a culture of open communication; I try as much as possible to have more conversations in public spaces, where other engineers are involved, so everyone is more comfortable sharing things they are working on, but also so it’s easier for newer team members to pick up on that culture of open communication and transparency. I find that this helps a lot by allowing engineers to share their work, and it also benefits the team overall when everyone is aware of the work each person is doing.
What mistakes do first-time engineering leads often make when transitioning from individual contributors?
I would say one very obvious mistake I see new engineering leads make is still trying to solve every problem that comes on their desk instead of delegating. There’s this tendency we have as engineers to always want to be the ones to find solutions to problems that are presented to us; it’s even more tempting when you’re a lead, and you have access to a wide array of problems that you can pick from. Aside from the risk of early burnout, another issue with this is that you rob your team members of a valuable opportunity to learn and apply their creativity.
Another mistake I see often is that newer team leads tend to refrain from demanding excellence from team members, and I think the reason for this is because some of those team members were perhaps your colleagues as an individual contributor, and so it feels awkward to have to demand that they meet certain standards. I think it’s rather important to understand that being a lead already implies that your team members trust in your ability to lead, and so it’s important for you to take on the role and all that comes with it without feeling awkward about it.
As AI-driven systems become more common, what architectural skills will engineers need that aren’t talked about enough today?
An obvious skill I don’t see many engineers seek to learn today is how to architect complex agentic systems. I find that in most companies, the ideas engineers have about Large Language Models (LLMs) is that they see them as just another service being integrated via an API call, but I think this is a big mistake. Language models are inherently non-deterministic, and treating them as deterministic services tends to cause issues in the long run. I would advise more engineers to learn how to truly build agentic systems and workflows, understand the mechanisms behind how language models work, and evaluate and improve them as well.
How should African engineers prepare for leadership roles in an AI-dominated software landscape?
I would say more engineers should start learning the fundamentals and intricacies of software architecture at both the application and infrastructure levels. An AI-dominated software landscape means that engineering leadership roles will be less “managerial” and more “architect-y”. As the barrier to writing production-ready code reduces, the burden would shift to effectively architecting large systems across different domain-level constraints.
If you were to design a framework for the “next generation” of software architects, what would it prioritise?
I’d say the next generation of software architecture should prioritise decision quality, adaptability, and human understanding over static correctness. The next decade will be filled with many AI-embedded systems, so it makes sense for architects to design software that can explain its decisions, adapt as data and policies evolve, and remain understandable to the people who build, operate, and regulate it. What that would mean is having clear system boundaries, built-in observability and reasoning traceability, flexible policy-driven designs, and intentional human-AI collaboration (I think this, in particular, will prove to be really important).
What part of your journey would surprise people who only see your current role?
I would say maybe the fact that there used to be a time when the only way I could work was subscribing to a 500MB MTN Night plan (that ran from 12 am till 4 am), and then using the night plan to download course playlists from YouTube, that I could then study over the course of the day. Sometimes that also meant that for pieces of code I wrote that required testing integration with an API, I had to wait till midnight before I could actually run them to confirm they worked.
What advice would you give to a young engineer building under constraints similar to yours?
Be consistent. Nothing beats just showing up, even when you don’t feel like it. Keep showing up and showing your work through as many channels as possible; great things happen over time.
Finally, what kind of problems excite you enough that you’d still work on them even if no one was watching?
I genuinely have a passion for solving problems that have no clear definition and are, by nature, ambiguous. I would say this is one of the reasons I love software architecture, so, to be honest, any problem that can be modelled as a technology problem already sounds exciting to me. However, I’d say I genuinely love building in the healthcare and finance spaces; I could spend days architecting a flow to solve a problem in either space. I think it’s because those are two of the areas that have such a big impact on people’s livelihoods, and so being able to think about possible solutions genuinely makes me feel fulfilled.
Thank you for your time. It’s been a pleasure talking to you.
Thank you for having, the pleasure is mine.
