🏡 City: Near Nantes, in the Muscadet wine region

💼 Job title: Chief Technology Officer

🔮 Languages: English 🇬🇧, French 🇫🇷, Japanese 🇯🇵, and once even Mandarin 🇨🇳

👣 How do you commute to work? By foot, since I work fully remotely it is far!

✈️ Travel dreams: The Trans-Siberian Express

🎬 Favorite film: Tie between Blow-Up & Blade Runner


📌 How has the Engineering department evolved since Stuart's early days?

I joined Stuart five and a half years ago as the Head of Engineering and at that time, the Engineering department was probably about a little under one year old. The department had gone through a lot of turbulent changes and when I joined things had already started to stabilise. Originally, the platform was a PHP monolith, was struggling with even low volumes of throughput and was buggy. So the CTO made the decision to rebuild with Ruby. Consequently, the PHP team had a choice to say either, “Okay, let's work in Ruby” or, “Thanks, but I’ll go and work somewhere else in PHP”. About half the team decided that they wanted to stay, and the other half decided that they preferred to go do something else.

We started to hire people to rebuild the platform. That was when we started hiring fully remote; we didn't want to limit ourselves to only local talent. We have had that full-remote DNA from very early on. We started with vertical teams that were organised by skill set: Mobile, Front-end, DevOps, Backend, QA, etc. 

From my first on-site interview, I saw that for Stuart to really lead as a Logistics-tech platform we had to have a great data team. With even modest delivery volumes, human intuition stops being enough to understand the underlying dynamics of last-mile delivery, so we needed to have a strong grasp on our data to be able to optimise effectively. When I transitioned into the CTO role a year after starting, I immediately began building a Data team comprised of data scientists, data engineers and data analysts. In early 2020 we then hired a great CDO to lead a new independent Data team and give it the best chance of success.

Organisationally we’ve been through a few transitions over the past 5 years.

First, Squads: in 2018, we introduced our own adaption of the Squads model to help foster cross team collaboration.

Next, there was team consolidation. In early 2020 after experiencing dramatic team growth we began consolidating our teams into departments. Front-end and Mobile were grouped into an Applications Department, Backend and Data Engineering (who were building Backend services consuming events) into a Platform department, DevOps, Security and IT Support into an Infrastructure department. We also created a department called Solutions, which groups our Customer Solutions Engineers team with a new Solutions Engineering team. This helped enormously reduce the load on myself as CTO and provided great opportunities for our senior Engineering leadership to grow into the Department Director roles.

After that, we developed Squads V2. In mid 2020 we introduced a framework for our Squads to help give them better guidance on their ways-of-working which we call “Mission Minded”. It mixed together best practices from Agile, 6-week cycles and double-diamond product development into our own development framework. It is a high-level framework that sets out required milestones in the product development process, but gives full freedom to how teams operate between milestones. We think of it like guardrails to help teams stay on the right path.

Finally, Squads as Teams: Now in mid-2021, we are embarking on another transition completing the cross-functional “Squad” evolution. Teams will be led by single Engineering Managers who are responsible for team delivery, team members’ growth and well-being. These teams are grouped together based on our business’ stakeholders—including Clients, Drivers, Operators, Engineers—each with its own Engineering Director to lead them. Those Directors then report up to our VP of Engineering. We loosely followed the exceptional Team Topologies approach for designing the groups and teams. The previous skill-based teams are transitioning into Communities-of-Practice, with Governance bodies providing technical oversight and coordination across teams.

So, as you can see, we’ve been through a number of significant transitions as the team has scaled from 20 to around 140 people. Quite a change! Each step along that path was an incredible challenge for me to redefine our teams and how I lead them.

📌 What are the founding principles you followed—and might keep following—to build a leading Engineering team?

I think there are two main principles. One is to build talent density. I always try to hire people who are better than me/us. Hiring the very best people ensures that you keep learning and you’re achieving the best results. Because great talent thrives on learning, it creates a virtuous cycle of learning and improvement. Then great talent attracts great talent, so the cycle continues. One example of this is our Ruby team—I think we probably have (at risk of being too outrageous) the best Ruby team in Europe. The level of the quality of the people that we have here is really exceptional.

The other principle is “soft over hard skills”. When we say we hire great people, their greatness comes at least as much from their soft skills as their hard skills. We set a high bar for the hard skills, but the bar is even higher for the soft skills. People are what make a team, and a team is what makes success. So it's about taking your hard skills, your ability to work in a team and your ability to be creative in finding solutions. In the end, having people that are going to work well within the team is paramount.

There is actually a third principle, which is more about the leadership culture that I try to promote: to lead from behind as much as possible. As a leader, the goal is to provide direction for the team. Once that direction is given, the goal is to provide context and to explain why it’s important. When trying to solve a problem, giving context comes first. Alongside that context, I give full control to the team to achieve the outcome it sees best suited. With enough talent density it just doesn't make sense not to give full control to teams to achieve the outcomes needed.

Lachlan Laycock photo
Lachlan's management style is to lead from behind, but his equestrian style is to stand at the left

📌 If you had to pick just one engineering project you're particularly proud of because of the great team effort behind it, which one would it be?

Without a doubt, it would be the way we scaled the platform to handle 10x growth in London during 2020. Optisiming last-mile delivery is loosely based on the VRP problem which is considered an NP-hard problem, so it’s exponentially more difficult to solve as the size of the problem increases. Achieving that goal wasn’t easy, and we had some rough periods during 2020, but the outcome was a lot of excellent engineering and some very innovative solutions that drove dramatic improvement. Since then our optimisation services have been performing exceptionally.

📌 What's the philosophy you stand by regarding professional growth inside your department?

Professional growth is something we take very seriously in the Engineering department. I think it's fair to say that we've really been leading the way at Stuart with professional growth. We were the first department which came up with a structured growth framework back in 2017, based on the Snowflake framework.

Snowflake is a framework which is really appreciated, it values transparency, and tries hard to be objective. People can know at any one time where they are within the framework, where everybody else is within the framework and what levels different people have.

Because we have transparent salary ranges at Stuart, everybody knows that somebody who has an equal level of growth, has an equal salary to them—not exactly to the dollar, but an equivalent salary to them. You have a sense of transparency, objectivity and equity, which is really important amongst the team. You have a lot of freedom as well; people can choose how they want to grow within the framework.

Another great aspect of this framework is that it gives you an opportunity to make very clear to the team the things that we value about being a good engineer. Mentorship, project management, hard skills, accomplishment, supporting people through hard times, community spirit, etc. This gives people an idea of the behavior we encourage, and the behaviour which we don't necessarily encourage. For that, I think we've done well.

If there was an underlying philosophy there, it would definitely be around transparency and objectivity as much as possible, because no growth framework is 100% objective.  After three years of use, we have recently begun a continuous improvement process with our adaptation of Snowflake to evolve it around our needs as the team grows.

📌 If you had to give one piece of advice to an aspiring developer, what would it be?

Although it’s hard to give blanket advice, my best bet would be two things which kind of go together. Engineering is a job where you need two main things: creativity and great tools.

First, you really need to have various problem-solving abilities, and that takes creativity. Never underestimate the value of creativity. Then, to be able to realise your creativity, you need to have a great toolbox. As an engineer, those tools could be having a deep knowledge of different technologies and what they can do. Or could also be knowing how to build and organise teams.

So you should really sort of think about one, building a really strong set of tools in your toolbox. And two, that engineering's all about creativity. It's all about finding creative stories.

📌 What does your morning routine look like when you're working from home?

I have three kids, so the morning always starts with the school run. But between taking the kids to school and work, it's exercise. I’ll alternate between a session in the gym or going for a run, especially now that I'm fully remote myself.

0 pouet pouets