Engineering the perfect fintech product, whether it’s a new consumer bank or a solution for businesses, isn’t just down to lines of code.
Hiring that team is a challenge on its own, but especially so in a rapidly scaling company. Not only do you have to find the right people for the team, but you also have to manage the constant changes in your current team and company structure.
Lucas Bédout, Head of Engineering at Spendesk, joined Disruption Talks to discuss the secrets behind and the challenges of building and scaling a tech team. He explains why seeking out natural problem-solvers is one of his priorities, the importance of developing connections with your colleagues, and how to manage a growing team.
Spendesk’s impressive growth has seen 100 new hires added to the team in 2021 alone and an extension of Series C — another €100 million in funding announced in January 2022. According to their blog, this new funding will be used “to develop and upskill our team, invest in employee wellness, and attract and hire the best talent for Spendesk.”
Spendesk's growth was why we wanted to get Lucas’ insights on what it takes to scale tech teams.
Sean O’Connor: Could you give us a short introduction to yourself?
Lucas Bédout: When I was still in school, I decided that I wanted to start work early. At 18 years old, I got interested in coding and decided to follow that path.
I was lucky enough to get hired for a few small jobs and discovered the joys of engineering and SaaS companies. I worked at a few companies before joining Spendesk, which ended up being the best decision I ever made. We started with two in the engineering team, but now it’s constantly growing.
What does a typical day look like for you?
A typical day has a lot of meetings, with not much coding anymore. We have a big team, around 70 people now, so there are lots of meetings and keeping up to date on projects.
There’s a lot of cross-functional work as well because I’m involved with the other leaders in the company, including product sales, customer success, and of course, the technical teams.
How difficult do you find stepping away from coding and entrusting the work to others?
It’s all about hiring the right people, and at Spendesk, we look for human beings rather than just skills. I’ve always been keen to find people who are great problem-solvers. If I were to start a company tomorrow, I’d ask everyone I interview about a problem they don’t know how to solve, just to see how they react to something they’ve never seen before.
Every time you scale something, you encounter problems that you haven’t seen before. That’s why it’s crucial to hire problem-solvers.
How important is it to find people you work well with and have a connection with?
It’s the most important thing. You don’t have to be friends with everyone, but in the beginning, you almost have to be. If you’re in a small team and you go for lunch, you need to get along with the people you’re working with.
If I had to do it all again, I’d invest more time with the first few people in the company, making sure we can chat about topics even if we don’t have the same interests.
Would you say company culture is one of the top priorities in the company? Or is company culture just a buzzword?
It’s definitely a buzzword, but it’s still important. Company culture has to come from the people. The company doesn’t decide it, even though some will try to write what the culture is. Your culture is the people you hire.
It’s definitely very important and something we evaluate when we interview people. I like to ask completely random questions like, what job would you do if you were born in the 1800s, to open up discussion.
What’s your mission for Spendesk? What are your primary KPIs?
For Spendesk, it’s, of course, about growth. On the engineering side, one thing we’re looking at is retention. Retention is really important because we’re hiring at scale. If many people are coming in but many people are also leaving, the net new people isn’t great.
We like to make sure people have a clear path and a growth perspective in their careers.
Another thing we’re looking closely at on the platform side is the number of bugs. We aim for 99.99% of our sessions to be bug-free. It’s better to look at it that way than saying, “I don’t want more than ten bugs,” because it’s easier to understand if your product is good or not and where it needs investment.
The third thing we’re focusing on is developers’ productivity, so build time, lead time, and how long it takes to take an idea and put it into production. There are many things that may break when you grow very fast, and tools might not work anymore, so we invest a lot of time in that.
How does the team at Spendesk manage to hit ambitious targets?
Building a product is all about making sure to prioritize, making sure that you just do what's essential and do it right.
You don’t need to do everything at the same time. That’s what good engineering is all about. If you build a system too big too soon, it’s going to fail. That’s basically what we did in the beginning. We tried to do everything at once.
We’re investing a lot into monitoring and making sure we have visibility on everything that we do. If you don’t have that, how will you know if your product is working? You shouldn’t just build things and wait for customers to tell you it’s not working because most of them won’t. They’ll just go elsewhere.
Spendesk also does design reviews where you make a proposal for a design and then work with the senior engineers on the challenges of it and the cost to iterate it. We look at whether the ideas are too complex, potentially buggy, and how well they can scale.
How do you manage innovation at Spendesk?
We have two different teams, the product team, and the engineering team. While they work closely together, they work in squads in different ways. It’s not my job to innovate, but it is to push the product team to do so.
My team is responsible for engineering solutions rather than innovating design features. We work on finding the right solutions and advising the product managers and designers to make innovation possible.
What would you say is the biggest technical challenge in developing a product?
The biggest one was when we realized that the product wasn’t performing as it should have. As with any performance issue, we looked for exactly what was failing, but we couldn’t figure it out.
What we realized was that it wasn’t just one thing. Everything was starting to sub-perform. Eventually, we discovered that it was down to the whole codebase being too big and older designs not working anymore.
The main thing we learned is that we looked at it too late. We had monitoring, but we waited for the customers to complain when we should have been on top of it.
Do you have any guidelines when you’re hiring regarding engineering or coding?
We have some principles, but we’d rather give guidelines to people than tell them exactly how to do things. One of the principles we have is to value readability over performance.
I’d rather have code that is extremely readable, easy to understand and modify, than code that’s hard to read but performs faster.
Code that’s easy to read can always be tweaked. Code that’s hard to read may be really fast in the beginning but if no one can change it, it’s going to be slower because no one can work with it.
Other than general drive, is there anything you’ve worked on personally to get to such a great position so early in your career?
I’m really interested in understanding why people behave the way they do and the diversity of people you manage, whether that’s cultural, psychological, or just how people react.
As a manager, you need to adapt and look at yourself, what you’re doing wrong or right, and tie that into how different people work. A lot of the success you have is linked to the people you’re working with.
If you had a magic wand and could give every 12-year-old in the world a brand new skill or piece of knowledge, what would it be?
The first thing would be empathy. Being able to put yourself in the shoes of the person in front of you is going to help you and others throughout your life.
The second one would be introspection, being able to look at who you are and what you want to do, rather than following whatever your parents have planned for you or where your friends are heading.
This discussion is part of our Disruption Talks recordings, where we invite experts to share their insights on winning innovation strategies, the next generation of disruptors, and scaling digital products. To get unlimited access to this interview and more insights from industry experts, sign up here.