Jo Wickremasinghe, CPTO at BPP DISCUSSES bridging product and technology

‍Host: Lucas Hendrich, CTO at Forte Group
Guest: Jo Wickremasinghe, Chief Product and Technology Officer at BPP

Introduction

Lucas Hendrich: Welcome to the CTO to CTO podcast, where chief technology officers dig into the challenges and opportunities leaders face every day at the intersection of business and innovation. I'm your host, Lucas Hendrich, CTO at Forte Group. In our second episode, I sit down with Jo Wickremasinghe, Chief Product and Technology Officer at BPP, a leading edtech company based in the UK. Jo shares her journey from aerospace engineering to leading high-performing technology organizations. Here's the conversation.

Why don't you tell us a bit about who you are and how you got to be here in front of us?

From Aerospace to Tech

Jo Wickremasinghe: I'm Jo Wickremasinghe, and you can tell by the accent that I'm not British. Well, I am British, but I'm Australian, born and raised. I've been in England for more than 25 years, so I've spent about an equal amount of my life in both parts of the world, which is great.

I started life as an aerospace engineer. That's actually how I moved to the UK: I worked for Airbus and came over here to build airplanes, working in Bristol, where we have a big factory. But this was the late '90s, and aerospace was not what I thought it would be when I studied it at university. It's very slow-moving, and it takes many years to bring a new aircraft into production.

At that time, the late '90s, there was the dot-com boom, if that rings a bell for anyone. It was very exciting to be graduating from university and working then. I was an early adopter of technology. I loved computers — I didn't really play games, but I loved using them to make my life better. I could see the endless possibilities for productivity gains from technology, so I knew I wanted to get involved.

Microsoft and the early web

Jo Wickremasinghe: I made the leap around 2000, which is interesting because that's when the market kind of fell out. But I managed to get a job at Microsoft, and that's really when I started working for a pure-play tech company. It was amazing. I was there for seven years.

I started on the technical side, in operations. We ran all of the web services for MSN, which used to be really big back in the day. I was a project manager: I took my project management skills from aerospace engineering into Microsoft and worked in the website operations team, running all the projects to launch new websites.

One of our biggest events was the launch of a Harry Potter movie. We ran promotions and campaigns on the website, and it drew a massive amount of traffic. So I got to understand the back end of web technologies back then. I was around when Facebook first launched — I remember some university students who were interns with us starting to use it in the office, and I was like, "How do I get on that?" You had to get invites. It was incredible. The early noughties were an amazing time to be involved in tech.

Moving into product

Jo Wickremasinghe: While I was doing that, I decided that just project-managing the website and the operational side wasn't the most exciting thing. I wanted to be involved in deciding which features people were using and what problems we were solving. That led me into product management, and I carried on from there.

I did an MBA while I was working, because I wanted to understand the business side. It's not just about building cool products — they need to make money. That's how it went from the early noughties all the way to today.

I've stayed mostly in the UK. I've worked a little in the US, mainly on secondments, and I've been really lucky to work for some amazing British tech companies, and for brands that maybe aren't tech companies but have technology at their center, like the BBC — huge audiences, and really innovative in the UK.

I've worked in multiple sectors: media, health tech, the property and marketplace spaces, and now edtech. For me, it's never about one particular sector. It's always about where the really interesting problems are, and how we can use technology to solve them.

I've loved it. I can't believe where I am at this stage of my career, because I feel there's so much more to do. And I'm quite jealous of the people coming into the sector now, because the opportunities are endless.

Choosing a Path in a Changing World

Lucas Hendrich: Absolutely. So much of what you said resonates, and there's a lot to pick up on. I've often found — whether hiring people, joining teams, or speaking with people like you — that many people in our generation grew up with tech in the '90s and then saw the explosion of so many interesting things during the 2000s: the evolution of SaaS platforms, frameworks, and ways of developing products. We often came through a path that wasn't really planned, finding interesting opportunities that don't always map to a university background.

This was actually going to be one of my last questions, and we'll get into the CPTO role too — that's a major theme I want to explore with you. But I have children, and the oldest is looking at college. All these opportunities are also kind of frightening. How does someone decide where to go, or try to map out their destiny? On the one hand, there are so many opportunities. On the other, you want some predictability. What advice do you give someone you're mentoring who's entering their career?

Jo Wickremasinghe: When I look at my team today, very few people who are maybe 10 years out of university are still doing what they studied. If you're a doctor and studied medicine, that tends to hold. But in technology roles, not many people went to university to study computer science — and those who did are probably doing amazing stuff in the AI world now. There are so many other facets to building digital products and services, and people can come from anywhere.

I have a 14-year-old who's making GCSE decisions now, and I've told him that, in a way, it doesn't really matter. He's being made to do maths and STEM because his father's a physicist and I'm an engineer, so he has to. I believe that if you have an analytical and mathematical mind, you can do pretty much anything in technology. But he's also very creative and artistic, so he might end up in a creative field — who knows?

I think it's really important to do things that are interesting, that expand your mind and challenge you. And the most important thing is a culture of learning. It's not just about absorbing text; it's about how you solve problems with knowledge. You get those skills from a wide variety of courses. It's less about being an expert in economics and more about understanding how economics can help you read people's behavior, or natural disasters, or whatever it might be. Behavioral economics will have applications all over technology and digital.

I know that's easy to say to a young person who's stressed about what to do, and worried about falling into a path that might not be right for them. I felt that way when I started working in aerospace engineering: "Oh my gosh, I spent four years on this engineering degree — what a waste."

But everything I know about the "T" part of my job comes from that. I wrote software for my engineering degree; I understand how software works, and that contributes to the CTO part of my job. All my work in finance comes from my mathematics and modeling background. There will always be things you take away from whatever you study — maybe French is harder to apply in technology, but there's always something.

So I don't think it's that important, though I really understand the challenges young people face. The reality is that the jobs they think they're going to do won't be those jobs. They'll be completely different. So I say: go with it.

Hiring for Problem-Solving, Not Frameworks

Lucas Hendrich: I want to highlight a couple of things there. Indexing heavily on the ability to grow and learn over being an expert — which only comes from feeling your way through things, solving practical problems, and applying the tools and mental maps you have — lets you jump from domain to domain. That could be really reassuring for people entering the job market. It sounds like you'd hire people who show those capabilities and that curiosity rather than going through a checklist: Do you know X, Y, Z? Does that inform how you build your organization?

Jo Wickremasinghe: I definitely see red flags when people regurgitate what feels like a product management textbook, for example. There are a number of amazing speakers and writers in our space, but some people just quote them and talk about their frameworks, not about how they've solved problems. For me, that's a red flag. Those aren't people I'd hire.

Nobody taught me how to do product. Nobody. I figured it out. It wasn't really a discipline back then. There were people at Microsoft in the US doing it, but we didn't have a Marty Cagan. We were all learning from each other and figuring it out as we went. A lot of it is common sense, and it's closely aligned with traditional product management for FMCG and physical products. We applied many of those similarities in a digital world, but you had to figure it out as you went.

So it was the people who could think for themselves and think logically who succeeded: How do I apply a marketing strategy to a digital product? How do I understand my end user, my customer, when they're an anonymous person on a screen?

I look for that today. I haven't hired at the graduate level for a long time; I've been hiring people with experience. But even then, five years of experience can look very different. What I ask is: What's the hardest problem you've come across? What happened? What went wrong, and how did you deal with it? Then I listen to their thought process.

It's a cliche, but it's not your successes that are most valuable for learning and development. It's the things that go wrong, and how you react to them. Even if you can't rectify the situation, there will be something you take away. I've certainly had experiences in my career that made me better the next time around. Those are the stories and evidence I want to hear in interviews.

It's absolutely the same on the technical side with engineers. It's great if you've built great software and know all the frameworks and languages you need. But when has it gone wrong? Have you had a security incident? An outage? How did you fix it? When have you had to rally around as a team to solve a problem? That's the really interesting stuff that helps me choose between candidate A and candidate B.

Lucas Hendrich: So when someone uses the metaphor that migrating to a new platform is like keeping an airplane in the air while changing the wings, you can relate directly.

Jo Wickremasinghe: I use that all the time to describe to stakeholders what we're trying to do every day.

Coming up next: the evolution of the CPTO role, what it means to lead product and technology in investor-backed companies, and the challenge of balancing priorities.

The CPTO Role

Creating the role

Lucas Hendrich: One thing I want to explore: talking it through, it makes total sense to have a role that combines product and technology. Ten years ago, it might not have, and many organizations kept them in separate silos. As CTOs evolved from keeping the servers running to being tied to revenue generation, those two worlds started to unite. In your organization, has the role always existed, or was it created around a need? How did it evolve? And most importantly, how does the board view it? Do they understand and grasp it? I think it's a major shift.

Jo Wickremasinghe: Yes, it's still not very common. I'd seen it in a couple of my previous roles, and it made complete sense to me. But this particular role, I created.

A headhunter approached me about a chief digital officer role, and I said, "That's not me." She said, "I think you should look at the job description first." So I did, and she talked me through the investors and the company. Reading the job description, I could see it was really a CTO and a digital transformation leader. They wanted someone to own all of the technology, and also to take a massive set of disparate legacy systems and turn them into an ecosystem that drives growth and introduces major efficiencies across the organization.

For me, that was a CPTO — a CPTO on steroids, because it had to cover everything. I've worked with CPTOs in the digital-only space, but this role covers every aspect. So I said, "It's really interesting, and here's everything I think this job needs. But I'll only do it as a CPTO." That would look right on my CV given my trajectory, it made sense to me, and it would help me hire the right people, because they'd have worked with CPTOs before. And they said, "As long as you take the job, you can call it whatever you want."

Lucas Hendrich: I think that's a genius approach. It turns the tables. Some people think that when a headhunter approaches you, you have to mold yourself to the role to pitch yourself. You turned that completely around. That's inspiring.

Jo Wickremasinghe: I was very fortunate that the investors and the CEO asked me what I wanted the role to be. Did I want to run laptops, the enterprise network, and the Wi-Fi? Did I want the help desk? Initially, I said no to a lot of things, because I wanted to be super focused on the digital platforms.

Now, two years in, I've taken on more. I've taken infrastructure. I don't need to worry about laptops and the service desk, but I work very closely with the IT director who looks after that. We've compartmentalized that piece because it doesn't need to change much. Everything else is now in my space.

Having done this for a really long time, that trust — the belief that as the expert, I know best how to define the role — has been incredible. Every day I think, wow, how lucky I am. And I think they're all quite happy with how we're doing and with how I'm delivering on what I said the job would do.

Why combining product and technology is hard

Jo Wickremasinghe: I realize it also sets an example for the directors on my team about what they might do with their careers. And it's very hard. Going back to your earlier point, there's no such thing as a junior CPTO. Unless you're a startup founder, most people are either doing product, or they're on the engineering path: engineering manager, engineering director, VP of engineering, CTO. It's very hard to do both, because they're very different skills.

I started in tech in an operations role. Once upon a time, I worked with Cisco routers and switches — the lowest level of the stack. So I understand a lot of the technology, even though I wasn't writing much software, and that's helped me a lot. My engineering team trusts me. I do challenge them, sometimes in ways that surprise them given my lack of expertise in some areas. But much of it is common sense: supportability, maintainability, performance, scaling. The language and tools themselves matter a little less. I think that's been easier for me than for most product people I've met over the years.

Conversely, very few of the CTOs and VPs of engineering I've worked with really understand the business side. They don't quite get that we need to make these things profitable. This may sound controversial, but we only need to make products good enough. You don't need to gold-plate them. You may not need 0.1-second load times — bad example, but you only need it to be good enough. If it takes another 50% of effort to get a 1% optimization, it's not worth doing. That business mindset doesn't come naturally to most CTOs.

That's where the gap is. It's why so many organizations have conflict between the CTO and the CPO, or the VP of engineering and the VP of product: they're optimizing for different things, and they don't report to the same exec. It's hell. I've worked in many places where that was a massive frustration.

Technology in service of the problem

Lucas Hendrich: You put that brilliantly. That leads to the next topic, though I don't want to jump there yet: what it's like being an executive in an investor-backed company, where you're not the founder but you're coming in to do something at a certain scale. Having that business sense is often counterintuitive.

As you said — I remember doing diligence on a company once, and they said, "We deploy to production a hundred times a day." I'm thinking, that's great, but what does it actually mean? What needle is it moving? Maybe that rapid deployment really is moving something forward, but it's hard to weigh unless you understand how it affects top-line revenue or the bottom line.

Here's a thesis I've been forming that I wanted to run by you. A lot of the hard technical problems we had to solve 20 years ago have been solved by better frameworks, or now by AI. There's a lot of scaffolding — work that isn't a big cognitive lift but just needs to get done — and that's becoming an enabler. When people talk about AI replacing people, it actually highlights the greater need: connecting technology to a concise problem and asking your engineering team the right questions, regardless of whether you know the exact framework. Does that make sense? I feel the role will only become more important over time.

Jo Wickremasinghe: I've always thought that would be the case. Another red flag for me is someone who says, "I only code in this language." I remember people at the BBC saying, "I'm a Perl developer. That's all I'll code in." And I'm thinking, you've put a pretty short timeframe on your career. Engineers have to move with ever-changing technologies. Their real skill set is how to solve problems, and how to apply solutions to them.

It's early days, but so far AI use cases are very specific — very good at solving one thing. Our world isn't made of point solutions. It's workflows, next best actions, and human interfaces. You have to join all of those up into an end-to-end working solution. AI might be one component, but it doesn't do everything.

We've had all sorts of technology solutions for a long time, and yet some of the most basic things in our lives still don't work. The streetlights on my road were out for three weeks. Three weeks! Something so simple, and you wonder where technology is making it better or fixing it. Someone still had to come and dig a massive hole.

So I don't think we'll all be out of jobs. First, jobs will evolve and change. Second, it takes a lot of effort to change humans, our infrastructure, and the way we live, breathe, and work. I'd love a house fully managed and maintained by technology, but all the infrastructure you'd need to unplug and replug means it'll be many years before we're all sitting around on a universal income, not working, and enjoying the spoils of a technology-driven world. The key to success in that environment is always being ready to adapt, try something new, and not be afraid of it.

Next on CTO to CTO*: Jo and I talk about organizational culture, talent, and the critical skills for the next generation of leaders.*

Leading Transformation Under Pressure

Keeping the airplane in the air

Lucas Hendrich: Let's talk about the pressures — about that airplane we have to keep in the air. You don't get many pilots who survive several crashes. In such an important role, you can make some mistakes, but not many. How do you handle that? And how do you build an organizational culture that gives people space to grow, while carrying the serious pressure of understanding the business implications of many of the decisions you make day to day?

Jo Wickremasinghe: Where I've seen what we're trying to do here fail is in the idea of digital transformation as a massive undertaking. I've generally seen it done with a lot of investment and not much return for a long time. The problem is that in 12 months your whole business and environment have changed, and you probably need to throw away everything you've done because it's no longer worth it.

I know that's the foundation of Agile, and we all understand it. But my impression is that many people think you can't do Agile during a transformation, because you're moving a big monolith into something else, and that takes time. I just don't believe that's true, and we've proven it where we are.

It's a balancing act: finding quick wins along the way while doing some of the heavy lifting in parallel — not quite keeping the wolves at bay, but something like that. You know there's major re-platforming to do. As a leadership team, we always try to slice things as thinly as possible: What value can we ship as quickly as possible?

But a few things we're doing this year will take six to nine months before the value is out the door. I hate that. It really frustrates me, because I worry that while it's happening, something will change and we'll have to throw it all away. So I'm very paranoid about it. Staying close to it, continually removing scope, and thinning it out are key.

As an organization, you can't only do that. You have to find other things that deliver value along the way. But underneath it all, you don't do it in hacky ways that you'll throw away. We do everything while minimizing shortcuts and tech debt, and that's really, really difficult. It's a lot of plate-spinning.

Deliver value quickly, but sustainably. Do it on the new stack. Make sure you have the right testing frameworks and the right infrastructure. Think about security as you go. And make sure you're not building a bunch of dependencies on other teams and legacy systems. You're asking all those questions all the time.

Sizing the organization

Jo Wickremasinghe: I think team size is key. I wouldn't say we have an endless checkbook — we don't. I shaped the number of teams around a limit. I'm sure there's some science behind it, but it's probably experience that has turned into my best guess: any more than 10 or 12 teams running in parallel is too many for me to be across enough to see all the connections.

That's where I add value. I can say that a team over there is doing something that might affect a team over here, and make sure they're not pulling in opposite directions on the tech stack or the roadmap. In a really large organization, that becomes next to impossible unless everyone can run independently — and we can't, because we're building this foundational platform in lots of parallel slices.

So I naturally capped the budget ask, because I knew that was about all I could hold in my head at once. I don't know how my CEO… well, they wouldn't have given me more money anyway, so that was a good thing. And we went as fast as we could.

Structure, discipline and alignment

Lucas Hendrich: I think that also forces urgency and constant questioning. It ties to something you said earlier: sometimes people talk you through Agile or product development by listing the typical practices and why they matter. But in the end, it's about real discipline. The idea that Agile is big and flexible — throw paint at the wall and figure it out as we go — is a huge misconception. You have to be very disciplined in every ceremony and stay focused on that.

Jo Wickremasinghe: I'd argue we're more structured than most IT projects. We have a three-year roadmap. The details get fuzzy, but the big three-year goals are in my head: I want to be off certain platforms, and I want foundational experiences in X, Y, and Z domains. Then we can become more innovative as we go. I painted a picture for the exec team and the investors of where I wanted to be, and that's the big-picture roadmap we're sticking to. What we do in what order, and which problems we solve, we work out as we go.

We have our vision — actually a five-to-seven-year vision — and we ask what it looks like in three years. What does the roadmap roughly look like? How do we get from legacy tech to new tech? Then we sketch quarters one, two, and three: roughly where we want to be by the end of year one, carved into four quarters.

Every quarter, we review and reflect. The Agile ceremonies force that anyway, but we ladder it up: a two-week review feeds a monthly review, which feeds a quarterly review, keeping meeting time to a minimum. It's really helped keep everyone moving in roughly the right direction, and lets us reprioritize as we go, because we reflect together and stay focused on the big goal. It's very structured, even rigid in many ways, but it's working.

I don't think the teams feel constrained. We do a lot of feedback and surveys, and they all feel they're innovating. The problems they're solving are fixed, but how they solve them isn't. I think that's all they want: the freedom to be creative in solving those problems.

Lucas Hendrich: People don't think of rigidity and alignment as synonyms, but they almost are. You create alignment and people stick to it. It may seem rigid, but it actually makes people feel successful in their jobs, because they know they're contributing to something shared across all teams.

Jo Wickremasinghe: And I think it's leadership's job to make that work by reflecting the impact back to the teams: this is the revenue you're driving, this is the CSAT you're driving, this is your impact on these metrics. Then they feel they're really making a difference.

I've worked in organizations where all I heard from cross-functional product teams was, "We don't have any autonomy." And I'd ask, why would you get to decide which problems to solve? The company decides that. I heard it for years — product teams saying they had no autonomy to decide what to work on. How is that possible? That's not how business works. Maybe in a startup. But I tend to work in more mature companies that have lots of problems and lots of customers. For me, that's exciting: you have people you can talk to and understand, and you can figure out how to use technology to make their problems go away.

Engineers Who Talk to the Business

Lucas Hendrich: In line with that, and with the chief product and technology role, I like to talk to technical teams about business details. In the past, someone might have said, "Don't bore them with that. They just need to know what to build. Talk to them about technology." It's the opposite. Everyone wants to know. You want to treat them like adults in a room. I raise my kids so they can talk to adults, not so they stay at a certain level.

Jo Wickremasinghe: And things have changed. Ten or fifteen years ago — massive generalization — it was hard to find an engineer who wanted to talk to a stakeholder or an end user. Today, people are much more multi-talented. Maybe we're just lucky with our hiring, but the people on my team will happily jump on Slack or a Teams call with a stakeholder and ask, "What's the problem?" They'll come up with a solution and bring it back to the team to validate. A product person doesn't need to do that; the product person is thinking about the bigger problems. The engineers are very flexible, able to have those conversations, and able to show empathy.

Recently, an engineer found out that someone on our facilities team had to print codes one at a time. We place these codes around our buildings for people to scan, which is how we track attendance — we need that for regulatory reasons and for our students' health and safety. They were printing every single code individually.

He said, "That's mad." Nobody had flagged it. It came out of a conversation with that stakeholder, and he built a solution in about 10 minutes. I got emails from stakeholders about how wonderful the team is, just because that engineer talked to that person, listened to the problem, and realized it was easy to solve.

Building that kind of culture revolutionizes the organization. We have a lot of support across the business because people know we really want to help them succeed. And the engineers love it and get a lot of satisfaction from it too, which is great.

Closing Thoughts

Lucas Hendrich: Absolutely. This has been wonderful, and I really appreciate your time. It's super generous, and I think it's pretty inspiring. Anything else you'd like to share before we wrap up? Any questions for me?

Jo Wickremasinghe: I'm just really pleased you thought to ask me to chat, Lucas. We've only met a couple of times, and it's always interesting. You don't often reflect like this day to day. It's in these conversations that you think, yes, these are the things I've learned over the 25 years I've been doing this. So it's really nice to have these opportunities, and I appreciate it. I hope you found some of it useful and interesting.

Lucas Hendrich: This has been a ton of fun, and I'll tell you a couple of reasons why. First, we don't often get the chance to engage like this. Usually we engage as business partners — someone's a customer, someone's a provider — whether that customer is an investor, or an internal or external customer. We don't have time for these kinds of conversations.

Often the structure for this kind of engagement is a conference or a keynote, and I get tired of those. They're fun, but there's always that layer of "let's go have a drink at the bar and then have a real conversation." It's a bit early in the day for me, so no drinking here. But I think these conversations are valuable because they expose people to the thought process.

One thing you said really resonated. One practice I try to keep is having a mentor who's maybe 10 years ahead of me in my career, and mentoring someone who's 10 years younger. Having that balance — someone who's been there to help move you up, while you pull someone else up along the way — is a great exercise.

It's also great talking to someone from the same generation. When we came into the job market, there was this big gap: all this new technology, and it wasn't clear who was qualified for it. If you were lucky enough, you just dove right in. So, Jo, this has been really wonderful, and I really appreciate it.

The last thing I'll leave us with is that you're an inspiration in many ways, especially since I have three daughters. When my oldest hears this podcast, I think she's going to feel much better about her future.

Jo Wickremasinghe: Well, thank you — that's exciting. I think they have everything to look forward to. Thanks for your time, Lucas. It's been great.

Lucas Hendrich: Thank you. 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.

‍