How do you lead technology organizations that prioritize fast learning, flexibility, and delivering real value?
Jamie Webb applied his vast fintech experience to transform an online pharmacy into an integrated healthcare platform. Find out how he enables fast delivery in highly regulated business environments.
The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.
“To ship something as fast as possible, it’s not about how quickly you can build it”
Moving fast and breaking things doesn’t cut it when a single mistake can ruin the business. In a risky industry like healthtech, you have to walk before you can run.
With vast experience leading fintech development teams, Jamie Smith Webb understood this all too well when he joined Numan. Having led their technological transition from an online pharmacy into an integrated healthcare platform, he joined us to share what he’s learned along the way.
In this interview, Jamie explains:
how to create tight and robust feedback loops in a complex environment,
what it takes to enable fast delivery without breaking regulatory compliance,
the importance of knowing when to deprioritize speed in favor of safety.
But first, find out more about Jamie.
About Jamie
After nearly two decades in fintech – most of it in engineering leadership roles – Jamie transitioned to healthtech and became the CTO of Numan in 2022, before transitioning into the CTPO role in 2025.
Apart from being a tech leader, he’s also a father, runner, and cyclist. His experience includes building outstanding engineering teams and organisations with a culture of speedy delivery and an eye for long-term strategy.
Meet Jamie
Arkadiusz Kowalski: Hello Jamie. You’ve been the CTO at Numan for almost 3 years now. How has that time been for you and the company?
Jamie Smith Webb: Hi Arek. It’s been fantastic. I joined Numan because of the mission and the people. When I talked to Sokratis, the founder, what came across was a genuine passion to help people live longer, happier, healthier lives.
One of our values is “patients first”. You see this in everything we do. Having a team that’s behind the mission and committed to making big strategic bounds has been terrific.
Two and a half years is a long time for a technology company. What kind of organization did you inherit when you joined, and what did you set out to change?
When I first encountered Numan, it was an online pharmacy, very much an e-commerce business. The team, architecture and mental model were primarily focused on marketing and growth – but with big ambitions and a strong patient-first mission.
I joined to build an integrated healthcare platform that helps people extend their healthspan. The majority of what we did the first year was rethinking our architecture and overall technical direction, as well as changing the setup of the team to allow us to get there. Following Conway’s Law – your architecture follows the way you set up your organization.
The goal was to help our clinicians and customer care team do their job well. We reoriented our teams around our platform. That was the first phase of transformation.
At the moment, we’re nearing the end of the second phase – bringing the business together in a way that’s aimed at achieving common goals across all functions.
Has your experience in senior roles in fintech been helpful in these efforts? What lessons carried over into your work in healthtech?
I didn’t have to learn to interact with regulators from scratch. I came into Numan thinking, “I know how regulation works, I’ve been in fintech.” But, as I learned more about healthcare, I realized how naive I was.
We’re regulated by multiple regulators at Numan. The burden of that is huge, and quite a few notches up compared to fintech.
But I already know that technology allows scalability, safety, and better outcomes even in a highly regulated area with lots of considerations and risks. I understand how to make the right arguments and work collaboratively with clinicians, medical directors, finance teams, and commercial teams. I’ve been through that journey, so I’m not scared by it.
My personal opinion is that healthtech is about 10 years behind fintech. I worked in fintech for about 20 years, and this moment feels to me like it did 10 years ago in fintech. The regulators and the industry are only starting to understand the real potential of what technology can do in terms of delivering innovation that can transform the lives of patients and the sector for the better.
Like you said, you transformed from an e-commerce to a platform, and now you’re becoming a cross-functional organization. Let’s talk about this from the perspective of a CTO. How do you design feedback mechanisms between engineering, product, and clinical teams so insights flow quickly and responsibly?
Getting that feedback loop tight and robust enough so that we’re building the right software in the right way – it’s extremely difficult.
The unique challenge in healthcare is that, at the end of the day, you’re affecting people’s health. From a clinical perspective, we have to ensure that we don’t do anything that puts our patients at risk. At the same time, we need innovation, speed, and the ability to iterate quickly.
A year and a half ago, we had some level of collaboration between the product and engineering teams. But then, near the release, there was a process involving the legal and clinical teams that could take weeks. We had 6 or 7 software teams working with one small clinical team. Everything slowed down.
Now, we have product, engineering, and design in our teams, but also a role called Clinical Product. These are clinicians who understand technology. Their job is to ensure that we design software systems and the architecture around them in a way that deeply embeds clinical safety from first principles.
Our Director of Clinical Product trains all the clinicians in the teams, and works with our Director of Technical Strategy, Director of Engineering, and Director of Product Design to deeply embed clinical thinking in there too. We also have a Clinical Safety Officer to ensure our systems are really well looked after.
Every layer of organization has a clinical representative deeply embedded within, influencing how we’re thinking and working.
So those clinical voices are not just included but strongly influential in the product development cycle right from the onset?
I’d compare the clinical voice to cybersecurity and risk management.
If you ask our cybersecurity team, “What keeps you up at night?” – they’ll reel off 10 things right away. It’s the same with our clinical team. One mistake could jeopardise the business – and, more importantly, put patients at risk. That’s what we want to avoid.
Another thing we do are dedicated sessions where we look at clinical governance and information security governance. Every month, for two and a half hours, we go deep into the business risks, asking the clinical and information security voices, “What are the risks that we need to attend to?”
You mentioned that it’s quite difficult to balance the robustness and the tightness of feedback loops. But I’m curious – do you have an example of where a tight feedback loop led to a meaningful product or process improvement?
To give you some context before I go into the example, we have a team called Internal Tooling. Their mission is to help our operational teams – prescribing clinicians, customer care, dispensing pharmacy – be scalable, effective, and efficient.
One of our main propositions is obesity care, prescribing GLP-1 medications like Mounjaro, Ozempic, or Wegovy. We have to take every prescription seriously, so scaling that is a friction point. The efficiency of providing the information that our clinicians need to make the right decision is really important.
Thanks to the tight feedback loop, the Internal Tooling team helped clinicians safely reduce prescribing times. They are able to optimise their tooling for each and every prescription, allowing them to balance risk and quickly identify prescription requests that need more information.
Supporting the clinicians’ workflow while making it safer for the patients would not have been possible without a clinical product person in the Internal Tooling team. This enabled many quick wins – the clinicians love it and the patients are getting better service.
Building for speed and flexibility
That’s a great example. It makes me think that to be able to implement those tight feedback loops, you need to be really flexible. How do you build this flexibility into the development process without compromising on safety, compliance, or data integrity?
By ensuring that the process we follow as a team is all about short, iterative cycles. We don’t work on projects. We don’t say, “We’re going to do project X, design it, build it, launch it, put it into production, and then see if it was impactful.”
We prefer to say, “What is the goal we’re shooting for? What’s the real impact we’re trying to make? How do we quickly understand the right areas to make progress on?”
For example, the team wondered why people were coming off their GLP-1 prescriptions because of side effects – we call that pausing. Could we help them understand and manage the side effects?
It’s a risky area to get into. You could end up providing medical guidance in an automated way, which is a highly-regulated, software-as-a-medical device territory. You have to do it in a way that doesn’t fall under that regulation, but is still helpful to the patients, clinically accurate, and supports business outcomes.
To navigate that quickly, the team comes up with hypotheses and does small experiments around one shared goal. Thanks to having a commercial person, product and design people, and clinical people on the team, they get quick feedback which helps them move fast.
That sounds very much like Agile or Lean principles. Have they helped your teams move faster in this regulated environment?
The way in which we approach the development of systems that focus on delivering patient care is deliberately slower. We spend more time testing, more time with our clinicians and clinical product team, more time analyzing what can go wrong with defensive programming, more time with a clinical safety officer. It’s still relatively agile, but the cycles are longer.
Whereas things like changing a landing page around supplementation – as long as we get clarity and we’re using tools to help us do that – we can turn around quicker.
That’s how we apply these principles. The teams are deliberately slow and careful in some areas, and faster in other areas.
You also ran a survey on Numan’s LinkedIn page, and AI was selected as the trend to have the biggest impact on healthcare in the next 5 years. Are there any particular AI-driven tools or platforms that help you speed up delivery without adding unnecessary complexity?
Our engineers use Cursor. It cuts some time down, but it’s not the biggest AI-related thing that impacts our ability to deliver.
Our marketing team embraced AI early on. They’re using it for generating voice, image, and video for knocking around concepts. That has allowed them to be a lot quicker. It’s incredible to see. But there’s something that has even more influence.
The biggest impact of AI that I’ve seen across teams is easier access to information. I’m talking about the ability to do things like transcribing meetings, summarizing that with zero cost, and sending it out to everyone.
If you’re interested in what’s happening, you know a transcript is coming within minutes of the meeting ending. That provides a base layer of communication across the company that’s easy to access and understand. AI still gets it wrong sometimes, but it’s been quite a boost.
In terms of the development cycle, other than the coding advantages from AI tools, product teams are able to iterate incredibly fast on design. The ability to do that in hours just wasn’t there before.
You can imagine a world, relatively soon, where a cross-functional team goes from an idea in the morning to shipping it in the evening. Saying, “What should we do?” – knocking up a couple of prototypes within a half an hour, then using AI coding tools to support the engineers delivering that, and testing it with AI as well. You could see that cycle getting faster and faster.
Lessons from the past… and bumpy road ahead
Let’s talk about the mistakes you made or saw others make in the context of software delivery. What’s a lesson you learned the hard way when trying to push for speed or agility in a healthtech setting?
There are two big mistakes that I reflect on often.
One was not paying enough attention to the regulatory clinical side of the equation. My mistake here was trying to get our engineers to be as efficient as possible, delivering every day, without considering that in doing so we’ll break our processes, or we’ll break other teams in a way that they’ll have to catch up. That led to bottlenecks, frustration, politics, stress and anxiety in the organization.
To ship something as fast as possible, it’s not about how quickly you can build it. It’s about how quickly you can pick something that’s impactful, compliant, and clinically safe.
You need all the different disciplines together from the first steps of building it, rather than assuming that speed leads to more speed. It’s the old adage, “Slow is smooth and smooth is fast.”
The other mistake was assuming that my job was to get the architecture and the technical strategy right, and everything else would follow.
Whereas now, I’m starting with understanding the business outcomes well enough to say, “I’m making trade-offs that are suboptimal from a technical perspective but help the business.” The technical decisions are deeply linked to the specific business value we want to drive.
I’ve learned that technology isn’t an underpinning layer to the business – it’s integrated into it, all part of the same thing.
You shared the lessons that you learned the hard way. Based on your experience, are these the main areas that tech leaders get wrong when trying to go fast? Or are there other examples that you’ve seen?
There’s a really obvious one that I think many of us in technology, especially in leadership, overlook when we try to help teams move faster:
Spend time with your engineers and just ask them, “How easy is it to ship code here?” Then do it yourself, write a piece of code and ship it to see how hard it is.
If your team is dealing with friction all day, every day, it slows people down and demoralizes them. They can no longer take you seriously when you ask, “How do we increase pace?” You have to listen to what they’re telling you and develop a deep understanding of what helps them go faster.
Sometimes it’s the way code is shipped, or the meetings we have. Maybe senior leaders want to stay updated on all the details so the whole team gets involved and spends 3 days making a slide deck. It could be they’re missing a role in the team, or anything else – but the best you can do is really listen to them.
Several times, I’ve made the mistake of thinking that my idea would help the teams go quicker, but ended up making them slower. It’s better to sit down with the team more often and say, “Tell me, cards on the table, what’s slowing you down?”
General advice
Given all we’ve discussed, what advice would you give to tech leaders who want to help their team deliver faster while remaining compliant and flexible, especially in mission-critical fields?
Embed disciplines together in cross-functional teams working on clearly articulated shared goals. Give the teams space to express what would materially help them.
If you get those three things right – cross-functional, shared goals, listening to the teams – you’ll be able to accelerate rapidly.
Resources
Can you recommend some learning resources that could help our readers learn more about fast delivery in regulated environments? Anything in particular that you find valuable?
Regarding cross-functional ways of working and understanding how you really build a product, I’d recommend Marty Cagan’s books – “Empowered” and “Transformed”.
I’m on a bit of a product learning spree now, and Lenny’s Podcast offers great insights from a technology perspective, showing how great products are built at pace.
There are also two newsletters I’m reading a lot these days – “Refactoring” by Luca Rossi, and “The Pragmatic Engineer” by Gergely Orosz. They’re both massively valuable resources.
What’s next? 5 fast delivery practices
To build an organization that delivers rapidly while maintaining safety and regulatory compliance, Jamie advises that you:
structure teams and the organization in a way that enables short feedback loops, defining what roles can provide crucial insights and embedding them across all layers of the organization,
acquire a deep understanding of the business so that you can choose the most impactful issues to work on,
learn to make trade-offs that are suboptimal from a technical perspective, but enable you to deliver faster on shared business goals,
work in short, iterative cycles instead of projects, with cross-functional teams that can make well thought out hypotheses and verify them with small experiments,
ask your teams how easy it is for them to ship and what slows them down, then listen closely to their perspectives and do your best to solve their issues and remove friction.
When you organize cross-functional teams that work on shared goals and provide them with the support they need, you’ll be able to accelerate even in the most highly-regulated environment.
Authors
Arkadiusz Kowalski
When it comes to business, he strongly favors building long-lasting partnerships and value. Always enjoys meeting new people and coming up with creative ideas. In his free time, he is happy to chat about computer gaming, politics, and social sciences.