CTO interview: Matthew Wardle, changing the insurance industry from the ground up
Matthew Wardle built a company and tech product from scratch. With his co-founder, they’re changing how things work for the insurance industry, often seen as outdated in terms of technological solutions. Matthew explains how they changed the way the tech team of 25 cooperates.
Kasko is “InsurTech-as-a-Service”; it provides insurers with an end-to-end modular platform. What’s that in layman’s terms?
Insurance companies struggle with technology. They struggle to build products, put them online, and deploy them in more interesting ways. For example, APIs available to third parties. They struggle because they’ve been using the same tech for 25 years.
We’re a platform where insurers work with us; they provide the data such as documents, legals, underwriting rules, pricing, and we provide a modern frontend. From there they can push the info to third parties.
How much do you deal with APIs?
We in some sense deal with API providers and we are one. When you buy a plane ticket, it asks if you want to buy insurance for your trip, that’s done with an API connection going through a company like ours.
What motivated you to start this business?
I’m not going to say I was motivated by insurance. I’m the tech guy, my co-founder is the one with an insurance background. I’m interested in interesting technology problems and insurance is one. Think about banking for instance; what can an online bank offer you besides an app to see your transactions?
Insurance is quite different, because within one insurance company there are at least 100 products with specific differences. It makes the industry interesting from a tech point of view.
In terms of starting the company with my co-founder it was about having meaningful work that I enjoy doing and colleagues that I enjoy working with. I’ve worked in a big consultancy firm. It has its benefits, but the work in consultancy wasn’t meaningful as projects easily get dropped or no one really cared. There was too much time dealing with politics which is not what I wanted to do.
How big is your tech team today? How is it organized?
The tech team is 25 people (with Devops, QA). We’re divided into cross-functional teams: two core dev teams, and a DevOps team. It’s getting quite large for that process.
We’re at the point where we are re-structuring the teams because it brings communication issues. It’s a growing pain where we need a more scalable structure.
All the development team is in Latvia. It was an interesting choice a few years ago. I knew someone there whom I asked to join, and it just happened. They have a high-tech talent pool, clever people with good engineering universities, and strong work ethics. Quite importantly, the competition in Latvia in terms of other tech companies trying to find good tech talent is not that great so we’re able to offer a good package. By providing a good working environment, benefits, and competitive salaries you’re in a strong position, especially compared to web dev agencies over there.
What are the biggest challenges you faced when scaling? An example?
We originally made a classic system of a backend team and a frontend team. That was one of the very first changes that we made. If you need more of one of them, you add one and naturally split them.
Not thinking early enough about cross-functional teams is a problem. Not building an automated testing team early enough was an issue. The standalone testing function is key as the team grows.
The biggest growing pain was that everyone in my company, which is quite young, have worked in an Agile background before, but knowing that stuff doesn’t mean you can implement it correctly. In a sprint planning, are we achieving any of the benefits of the sprint planning? Why are we having stand-ups? Just saying what you did yesterday is pointless but sharing meaningful information should be embraced.
Building processes and making it right is the major thing.
How does your tech stack sustain your technical ambitions?
Our technology is all on AWS because this cloud solution provides a lot of pre-built functionalities and saves a lot of time. We could do cool things with Kubernetes, dockers, etc. but spending a lot of time working on them might not be the best use of time in a small team.
The users don’t care if you do cool tech in the background.
We decided to go for micro-services, more than 50 as of today, all connected. We decided that very early on, and it’s paying off now that we are becoming a big team. But early on, the devs will treat the micro-services like a monolith anyway, so is the work worth it? If I had to do it again, I probably wouldn’t start with micro-services.
Backend is running on PHP with Laravel but we’re now running our own framework to be more specific to our use cases. For the frontend, we were initially on Angular but we’ve been migrating to React because of performance reasons.
PHP is quite unusual as a choice for a young company. It was more popular 15 years ago for new projects. How come you chose PHP?
It was more of an issue of skillsets that we had. It’s also very easy to hire people with PHP. So many companies used it in the past so there’s a lot of talent with PHP skills.
If you want to connect with Matthew, click here.
To learn more about Kasko, visit their website: kasko.io
If you’re a techie working on something exciting or you simply want to have a chat, get in touch with me. I’m currently CTO at Kolleno.com
FROM THE AUTHOR
>> How Omni-channel Communication Will Improve Your Collections
