Building a High Performing Start up Engineering Team at Warp Speed

In this talk, Mikey Mo, head of engineering at Lantern, discusses the challenges of scaling engineering teams rapidly while minimizing technical debt. He reflects on his experience building in-house teams during a critical hiring period from 2024 to 2025. Mikey outlines the importance of nurturing a high-performance engineering culture, advocating for practices like collaborative code reviews and thorough assessments of cultural fit during the hiring process. He emphasizes the shift in hiring paradigms introduced by AI, urging teams to encourage candidates to demonstrate their problem-solving abilities rather than relying solely on theoretical knowledge. By implementing structured, lightweight hiring systems and focusing on team dynamics, Lantern successfully transitioned from infrequent software releases to a robust deployment pipeline, dramatically improving their engineering efficacy.

Uh our next um speaker coming up here, Mikey Mo, the head of engineering at Lantern. Uh he scaled five engineering teams in nine months. He's going to talk about what it takes to actually build fast without piling up technical debt. So Mikey would love to hear the answer to that. Join us on stage. Big round of applause. Could I get hold of the uh Oh, there it

is. Thank you. Hello everyone. I hope you've been enjoying the conference so far. Today I want to talk to you about building teams, especially when the pressure is on. This is a story about the hiring storm that we went through at Lancen from 2024 to 2025. I'm hoping there will be at least one or two things that you can take away with you to help you improve

the way that you hire especially in this post AAI world. So firstly a little bit about myself. So I am the head of engineering at Lancon. We are a startup and we are building a trusted data platform for private equity. I've been in software now for about 15 years. I actually started out debugging binary protocols at Cisco. I definitely don't miss that. Uh since 2018, I've been

in the startup world across various different industries. So, real estate, legal tech, agrch, interesting one. Uh and most recently, uh private equity. Most of these days I spend my time talking to people because frankly someone needs to and there's a lot of stuff going on and it's really hard to glue all those pieces together. Uh but on a good day I still get to code and with

these aentic tools it's really been a game changer for me. Uh when I'm not doing that I like to do problem solving on the wall. Uh and I'm also part of an improv group. And the thing about being an improv is that to be a good improviser you need to be a really good listener. And I think to be a good leader you also need to be

a really really good listener. So there's kind of a lot of um overlap there surprisingly. The story begins in May 2024 and this is when I first joined Lantern. And to be really honest, the engineering function was an absolute mess. Lantern needed to go for a change. Delivery was slow. And I'm saying about two maybe three production releases a year. Bugs were being found really late. Uh

so I think there were about maybe two or three QA teams and you know devel developers would do their thing and then they would hand over the software to the first QA team and then they would do their thing and then weeks later they'd hand off to the second one. It was just a complete chaos when it came to finding bugs. Despite all of that, we had

new customers that were coming on board and they were expecting really high quality software. They were expecting new features and we'd made commitments not just to them but also to our investors and our stakeholders. So yeah, we needed to change but there was a slight problem. See we had no in-house engineering team. was all offshored and no existing processes as a result of that no infrastructure. So

that production release that would take three hours of manual commands. I think during that time the cache would be warmed up and still to this day I don't know what that means. With no teamm you've got no culture and so we had to build that from scratch. So Charlie, our CTO, I think he's at the back hiding somewhere. On the second day that I arrived, he said,

"We need to build an in-house engineering team. There's loads of technical debts and there are two new products that we need to build. So help me hire four teams. Actually, wait, wait, no, five teams as soon as humanly possible." And so for me, this felt like Mission Impossible. To this day, Charlie says he still remembers the uh look of dread on my face. You may have heard

of the saying, building the car whilst driving it at 80 miles hour. Well, in my head, this was more like building the factory whilst designing the new car whilst selling the old car and building the new car whilst driving them both at 80 miles per hour. You know those action films where they have um you know the characters in their old car and they're like driving on

the speedway and then like there's another car coming and then they need to leap from one car to the other. That's literally what we had to do. But before I dive into hiring, let's talk about high performance. What does that mean for us? It's quite simple. It's kind of what everyone talks about these days. We wanted to shorten those lead times. We wanted to go from, you

know, production releases every few months to production releases every few days. We wanted to massively reduce the amount of bugs that were getting to production. And we also wanted to build a culture, a culture of a lot of collaboration and learning because there's a lot of stuff that's changing all the time and private equity is not simple. Here's a little dashboard that I agentically engineered. I think

that's the uh correct term these days. Uh so that all my teams can keep track of all of these metrics and so they just look at it in one place. And despite the fact we've got all these different systems like you know a system for bug tracking, a system for uh security issues, a system for feature flags and a system for deployments, they can all see it

on one dashboard so they know how well they're doing and what things they should be focusing on. If anyone else has done something similar to this, I'd love to have a chat. So now that we know what high performance means, we could start hiring. And after a few months in, we thought that we'd found a perfect candidate. And you know, we'd hired, you know, a bunch of

people up to this point, but this person seemed to have been really excelling. They were a really, really good culture fit, and they were nailing every single question that we were throwing at them. However, we use something called Fellow. Fellow is an AI note takingaking tool. Uh, it's in all of our interviews. And so, we h we record these interviews. And I usually kind of play them

back afterwards just to kind of review how I thought the interview went. And with this candidate, something didn't seem right. There were these long pauses. So we would ask a question and they would say yeah just give me give me 10 seconds I'll think about it and then they would return with the textbook answer. It's like you know the react manual basically the speed at which they

were talking was also changing quite a lot. So, you know, when they were talking about their past experience, they'd be like, "Yay, I did this and I did that." But when it came to technical questions, suddenly the the speed of speech slowed by about two Does anyone know what this is? Okay, so this is called Cluey and the marketing for it about 9 to 12 months ago

was cheat at any interview and it was also sound smart in any meeting once you get the job. I think they've changed it now because they've realized that uh that's not probably not the best marketing to go with. this candidate was using this tool and luckily for me I watched back the recording and they they shared it briefly on the screen and I had to go and

like do a bit of research like reverse Google search to find it. Uh but I did find it and uh yeah it will listen to everything that comes out of your speakers and it will read everything that's on the screen and then it will feed you uh what it thinks is the perfect answer. There's also this is your candidate who they say they are because I can

guarantee you at least one of the people we interviewed wasn't. So deep fakes are being used. Uh so if you notice that their face looks a little bit too smooth. Uh it might be the case that they are not who they say they are. There's a couple of ways you can get around that. There's the w uh there's the handwave technique where you get them to wave

their hand over their face and then they'll the deep fake software will get confused. I think in this one they've kind of just turned their head around. So hiring has fundamentally changed. It is not what it used to be. And it already changed when we had Google, you know, because anyone could Google things. But now you have all of this knowledge at your fingertips. So this takes

me to the first takeaway which is to focus on getting the candidates to show and to not tell. What do I mean by that? So like I said access to knowledge is really cheap. So if I was to ask candidate uh what is a Python decorator? They could find that out within you know seconds. But understanding takes time to build. It's not something that you can just

kind of magic out in thin air in a matter of minutes. And so we ask open-ended questions. We want to we want to give the candidates a chance to shine. And one of the best ways to do that is with a humble code review. So if you guys are not using code reviews as part of your hiring process, that is the first thing you should ever do.

And not only do they help assess the understanding of the candidate because say we'll we'll basically show them the code and we'll say what do you think of this code and they'll either say oh I think it's great even though I've spent about four hours trying to make it worst possible code I could possibly make it. Um or they'll you know share their opinions and then we'll

know whether we're aligned on what we think kind of good looks like. The other really good thing about it is that it's really really time efficient. So we screen out probably like 70% plus of our candidates within the first 20 minutes of talking to them because I can tell they don't understand the code. And in this kind of post AI world, you're going to be doing a

lot of code reviews. You're going to be looking at what agents are producing and you want to make sure that your engineers know what good looks like. Live coding is still essential. We actually allow our candidates to use AI tools in those live coding interviews as long as I said they demonstrate their understanding. Face to face interviews are coming back into fashion for that reason. As far

as I'm aware, it's still not possible to deep fake yourself in real life yet. Although at the pace that things are going, I wouldn't put it past us in the next 12 to 24 months. So with that in mind, you know, see things seem to be going well and a few months in, we'd kind of built a couple of teams. You know, we' started having um kind

of the resemblance of a good engineering culture. Um but I want to tell you a story about one of our tech leads. I'm going to call them John. It's not their real name. John was technically excellent. They loved solving hard problems. I remember sitting down and trying to debug some really gnarly front-end code with them. They were really, really fast, really, really productive. under the pressure of

what we needed to do, he had these really strong opinions and it felt like really, really good leadership. But over time, cracks started to show. There were disagreements and despite the feedback that I was giving, I wasn't really seeing much of a change in behavior and from these disagreements things weren't really getting anywhere. They were just kind of get escalating. People were like just starting to dislike

each other more and more and more problems were appearing in terms of misalignments of where we wanted to go technically, especially between those tech leads and those and so that tension grew. One day things tipped over the edge and in one of our team meetings John crossed the line that you can't cross. Uh I'm not going to go into that but we realized that he couldn't stay.

And so soon after that John left the company and after he left morale improved immediately. people started feeling excited to come back and and get things done. Those discussions that were just kind of spiraling and diverging and going out of control, those were finally actually concluding and we were finally making progress. Psychological safety returned and people felt comfortable to share their opinions again. So, one bad culture

hire tore through our entire engineering department. And when you're in the middle of it, sometimes it can be really hard to see that uh that as one person is making that much of a difference, but it was really really evident after that person left. So, we realized we needed to adapt our hiring. We needed to put culture at the center of it. And we needed to assess

for culture fit along every single stage of the hiring process. We realized that the strongest indicator for success at Lantern was someone who's a really really strong culture fit and a good technical fit as opposed to the other way around. I think you know the panel discussion just touched upon it a little bit just now but if you have someone who is really collaborative really low ego

is hungry to learn and take ownership of things it doesn't matter if they've not quite the finished product yet when it comes to technical knowledge it's a lot easier to build that if someone knows a lot and their values don't align with you it's incredibly hard to change And in the age of AI, the ability to learn quickly and collaborate is just becoming increasingly important. Um, our

job as software engineers is becoming more like product engineers. Kind of like what we said in this uh panel discussion just now, understanding users really working of others. We realized that good hiring mirrors good software development. So we cracked it about maybe 10 years ago when it came to software, we realized that you probably shouldn't do all your testing in month five, right? You should probably try

and find the bug as soon as the bug appears in the software. Well, the same comes to hiring. We want to find that cultural misalignment as soon as possible and we also want to find that um kind of knowledge gap as soon as And again, we want to do this in a show don't tell way because what is going to happen if you ask someone, are you

a team player? What are they going to say? Everyone's going to say yes, obviously. So, here's an example. So, let's say one of our values is collaboration because it is. So, how do we assess for collaboration? During our live coding sessions, we will challenge our candidates. will push back on something that they're doing and we'll say, "Okay, are you sure this is the right way of doing

it? Have you considered doing it in this way and then we'll see how they'll react? Do they get really really defensive? And if they don't agree, how do they communicate their disagreement?" That is a way better indicator of how good they are at collaborating. Similarly, initiative. Do they proactively say, you know what, if I had a bit more time, I would do this. I would improve the

code in this way. I would simplify it this way. Or in production, I would consider these things, but I don't have time to right now in the interview. Or are you being the one who's having to kind of uh squeeze those uh nuggets of wisdom out of them? This takes me to the final takeaway which is to create a lightweight system. When you are hiring at the

pace that we needed to hire and you needed to rebuild a legacy system and you needed to build new products, you needed to do all of that stuff. You need to make sure that you've got a system in place so that you can hire efficiently and you can onboard people efficiently as well. So we standardize all interviews. We put everything in confluence very very lightweight. Here's a

first stage interview. Here are the different sections of the interview. Here are some questions. Here are some model answers. It means that anyone in the team can look at that for probably about 10 15 minutes and just jump in. They don't need to spend hours prepping and we can make sure that the signals that we get from the interviews are relatively consistent. The onboarding checklist is something

that is extremely powerful, especially for a startup like ours. When you arrive, you want to know who should I be talking to? What are the things that I should be caring about? And where do I go for the resources that I need to access? The onboarding checklist answers all of those questions, and it quote unquote automates the onboarding process in uh in a very simple way. So

here's an example of one of our onboarding checklists. We have, you know, arrange your intro introductions with your team members. Add your details to your team to tell people what you like in terms of your communication style, in terms of the things that you're interested in. Go read through these five or six documents because there is a lot of stuff in Confluence and it's very very overwhelming

otherwise. So yeah, that's just an example. There's other sections like, you know, get access to GitHub, get access to Kubernetes. Here's how you set it all Building a really smooth CI/CD was also the number one priority for me because we don't want developers to not be able to deploy their code. So, we needed that to be completely seamless. So, like I mentioned before, it was a kind

of a three-hour production manual multi-stage process. when I joined. Now you can merge a PR and you can get it into production, you know, with a click of a button and it will run all the tests and verify everything. You need to get out of your way, get out of the way of the developers to let them get their job And with all of this, all this

cognitive load is removed from the process and you can genuinely scale and keep on top of the million other things that you've got going on in your startup. So to sum it up, we get our candidates to show their understanding through real problem solving. We're not just asking them to give us definitions of specific things. We put culture fit at the center and we continuously uh assess

for it. Uh we've got our head of data in the room as well and one of the things he likes to do is assess people's humility by asking them a question that they know they won't know the answer to. And if a candidate is willing to say I don't know, it actually signals something um that's very very important which is the willingness to say when you don't

know the answer. Be like I don't know but you know if I had time I'd figure it out and I this is how I would find the answer. We created a lightweight system to remove all the cognitive load when it comes to running interviews and on boarding people. So after 12 months of kicking this off, we managed to build five crossunctional engineering squads, which is around 30

We replaced 80% of our legacy application. I think I didn't say too much about it. It's a PHP monolith. I think there's two tests and if you run those tests, they fail. So 80% of that was gone. um replaced with uh some microservices written in Python. We got really really good test coverage and there was zero downtime during that process. We went from two deployments a year

to multiple deployments a week. So I'm pretty happy with that, but I would love to get that down to multiple deployments a day and that's kind of where I want to go next. And we got our change failure rate to under 15%. I think it's actually better than that, but back in 2024 this was considered good. I think now it's considered maybe not as good. Um, but

uh, yeah, back then that's what we were aiming for. Oh, we also launched two entirely new products at the same time. Thank you for your time. Culture fit is incredibly important, but it's also a great way to smuggle biases into your hiring process. How did you define culture fit inclusively? Oh, that is a really really interesting question. Um, so for us, I think when it comes to

inclusive hiring, it actually starts even before you even get the candidate in for interviewing. So we work a lot of agencies and frankly uh agencies can be quite lazy and they'll just basically throw you the candidates that um arrive in their inbox first. And so we'll go out and we'll say can you give me a candidate um that uh is more diverse right in in a in

various different ways when we realize that we've got imbalances in the team. Uh so for example um you know we didn't have enough kind of female representation when it came to technical leads. So we said, "Look, stop giving me like all of these CVs when like, you know, 50 of them are men, right? Go out and actually try and find some better CVs." So I think a

lot of it comes down to actually making sure that you get the right CVs in and you work with your agencies in the first place um and being really really aware of uh where you've got imbalances in your team. Looking back, could John have been moved back to an IC role? Was it definitely culture fit or was he overloaded? Um, I'm not going to go through exactly

what happened, but it was definitely a culture fit thing. Uh, for that specifically with the culture fit change and hiring. Oh, that's it. Thank you.