Luko’s Engineering Principles
Or what makes us who we are in engineering.
A little more than five years ago, Benoit and Raphael founded Luko. Since its inception, Luko’s team was focused on making a change in the way people experience home insurance and home care. The team built innovative software products that enabled digital and fast onboarding of our customers and a very quick response time to people’s claims and need for support with their home and insurance.
Early on, any startup is figuring out what works and what doesn’t, what will stick with the customers and what will not be appreciated, what helps them bring change and innovation very fast to the market and what slows them down. We have been through the exact same experience at Luko as well. We were building many different internal and external products that made a real difference to customers and the business. We grew from 0 to nearly 400 000 beneficiaries in a few years and achieved a response time to claims of up-to 2 days on average with customer support NPS of 64 and post-claims NPS of 17 at the time of writing. We built a Super App covering all services for our customers and a platform that supports the entire set of tools required for an insurance company. I believe neither of this would have been possible without our pragmatic approach and customer focus we are so proud of at Luko.
Enough about business 😃. This post is about our core engineering principles. I will cover
- How did we define the principles
- The engineering principles with examples
Where did we start?
Over the last 12–18 months, we have been scaling our team aggressively and our future growth plan is even more aggressive. Finding so many talented engineers, onboarding them into Luko’s way of working, letting them grow and enjoy being Lukooms requires a lot of different processes and frameworks. The key among all of those is a shared understanding of what we value in engineering and how we see our engineering culture and practices at their best. To define this shared understanding, we decided to formalise our engineering principles.
The first question to answer is where to start and how to define such principles. I have seen before such principles being introduced using a bottom up approach as it is about the people or using a top down approach as it is defining the culture the leadership would like to foster. Both approaches worked well. This time, at Luko, we decided to do the following:
- Have a discussion with the co-founder and CTO Benoît and see what is most dear to him.
- Analyse all the information we have from surveys, engineers feedback, the way our engineers work and execute, and more, and identify what makes us successful and is common among all teams.
- Think of what qualities we would like to emphasise and what we believe will make us successful.
- Use this information to formulate our engineering principles.
- Learn from the team if we got it right by asking them if those resonate with them and what examples they have that we practice those principles.
The outcome happens to be a little surprising and very satisfying. We were able to read the environment and what matters to people well. The feedback was clear that the principles (pragmatism, execution and impact) that were with us from the beginning of Luko are deeply embedded in our DNA and a couple of new principles (measure to know and automation) that we were working with the team in the past 9 months have been becoming a real part of this same DNA.
The Engineering Principles at Luko
Here I will present each principle and provide a couple of examples coming from our engineering team that demonstrate that we live up to the principle.
Execution
Luko’s success has been based on the ability to move very fast. We are proud of being able to make decisions, build and ship software fast and often. The faster and easier we can ship to production, the happier our engineers are. We use data to balance speed vs quality and ensure that our ability to ship fast and often is not affected by technical and process debt.
This is a key principle in engineering that has helped us experiment and move very fast with our ideas, new solutions and experimentation that helps Luko’s customers and the business.
We design and build products that solve the immediate problem for the business and customers. We test them on the market until we have a fit and traction. We learn and improve our products as we scale. We value our velocity and the ability to deliver value to our customers at speed. Many companies slow down when they grow and Luko hasn’t been slowing down a notch. In 2021, we shipped key products on the platform and brought all products and operations of a company we acquired to our platform in a matter of months. Other companies could have taken years, but at Luko it took months.
In 2021, we shipped on our Super App an entirely new product (full-fledged MVP) named Realty that helps our customers find their next home (buy or rent) in 6 weeks.
When there is an immediate problem or a solution that we should ship out the door with a fixed deadline, we happen to organise war-rooms and that works well for us. It allows us to focus and prioritise on what really matters for a project. After every war-room we have a celebration and a period to improve the source code and clean up known technical debt.
Recently, we had a little slow down in some teams and our engineers shared that they miss the healthy pressure and the usual speed we execute at. Everyone wants to ship more values to our customers.
Most of our teams ship at speed. We have multiple releases a day or a week or planned major releases as for the Super App. We adapt to the environment (Mobile, Web, Services) and ship as many times as it is needed to continuously bring value to our customers.
We have a standard set of rituals that every team follows; namely daily meeting, planning, retrospective and refinement (optional). Every team finds the way that works best for them, tuning those rituals and continuously improving our speed of development and quality.
This is the story of the team and examples people relate to when they think of the Execution principle.
Pragmatism
We solve business and customer problems with technology. It is not always clear if a solution will work well with the customer. Some are a great success and others not. Hence, a good judgement of how to make the most impact with a simple solution is important at Luko. We will not use a technology just because it is the latest hit. We will rather use a proven technology that is fit for our needs. We will optimise for speed and for a solution that solves the problem at hand. If it is a success, we can always further develop and scale it.
We have the responsibility to provide reliable, secure, performant and good quality products to our customers. This is the face of our business. If a customer needs help with a claim, they should have our Super App always working. If a customer would like to check on their electricity or gas consumption, our Super App should work at any time. Any of our products should be working as well.
Hence, we will choose a proven technology that fits our needs and stick to what works well for us over constantly running after the latest hype. We will balance the needs of today and the needs of tomorrow. Building a solution that supports five million users when we expect one million in the next two years makes no sense for us in terms of time, cost and maintenance.
On a high-level, we use the same stack in the different domains (FE, BE, Mobile). The teams might use some different libraries and tools when this is the best option for the problem at hand but overall we follow what works for us.
We build solutions that add value and not for the most beautiful code. We favour regular refactoring over building the perfect solution from the first version. We refactor when it fits our work best. It can be while working on a new feature, while enhancing a feature, an entire refactoring or a migration project. Recently, we decommissioned our contract system and replaced it with a much more advanced, flexible and extensible service. That was a total “refactoring”!
We balance velocity and quality. It might happen that, in order to meet an important release (new country, new product), we will consciously accept to cut corners while keeping good product quality and the aggressive schedule. After the release, we will take the time to clean up and move on. No doubt sometimes there are exceptions but this is what we aim for.
We know the knowns and we are aware of some unknowns. When unknown unknowns jump in front of us we are very adaptable. We will reconsider the roadmap and our plan and find a way to achieve our (adjusted) objectives.
Decision-making is very quick. Often the risk of a wrong decision is small and it is best to move on quickly and experiment instead of getting stuck in analysis-paralysis.
We are also very pragmatic when it comes to product decisions. We used to develop hardware solutions for Home Monitoring until one day the things on the market changed and there was an opportunity to offer a software solution using data from electricity and gas providers. Yup! We killed the hardware products and in no-time built a module in our Super Mobile App.
As you can see most people truly believe that this principle is part of our DNA and day-to-day work.
Impact
Luko is a fast-paced environment and everything we do is based on the impact it has on our speed of development and product quality,, customer satisfaction, business needs, and the satisfaction of our engineers. Each team owns their roadmap. Building and shipping software that has significant impact provides to everyone a sense of meaning and ownership. Everyone owns their scope and is accountable for the results.
Every engineer can make a technical decision and when needed request feedback via the RFC process. We make decisions that ensure that our products are secure, fast, and always work for our customers.
Our teams own their product and services end to end → discovery and design, development, quality and operations. This way a team follows and is in full control of the impact they make for the customer and the business.
We use annual and quarterly OKRs to drive the growth of our business and impact on customers. Every tribe and team define the work that will have the biggest impact for our customers and business. Every team and individual has a clear idea how their work and decisions make an impact on the our objectives.
Our latest survey has indicated that the majority team believes that we follow those principle.
Measure to know
We truly believe that, if we do not measure, we do not know. One can often hear us asking each other the question “How will we know that X had the desired impact?” or “How do we know that X leads to Z?”. We measure everything and continuously aim at improving the way we build, ship and operate our software. This allows us to quickly adapt and maintain a high velocity and quality.
Any change is supported with data. We define metrics that will help measure the change and set the baseline. We monitor the change, learn and make a decision on what to do next. This is our approach from personal, software, recruitment, product and any other improvement initiatives.
- Product improvements are measured with the KPIs we want to improve. We use A/B tests, conversion funnel metrics, number of visitors, MAU, churn rate, and more.
- Indeed we also measure recruitment improvements. We hire a lot and without data we are blind. We measure the hiring pipeline speed, the time to hire, conversion rate, and more.
Reliable software operations and software that works as promised to the business and the customer is very important. We use SLI and SLO to define the indicators we follow and thresholds that we do not want to exceed. SLI and SLO can be purely operational and software such as response time, TTI, error rate and can be more business oriented such as price accuracy, drop-off rate, and more.
This is one of our newly adopted principles that has been in place for the past 12 months. We have made solid progress so far and more has to be done.
Automation
We favour any form of automation over manual work. Anything that can be fully automated should be. Automation speeds up shipping and saves time while allows us to ensure repeatable execution of the same test, script, pipeline minimising the potential human error. Automation is at the core of increasing our productivity and making shipping of products easy and fast. It is deeply embedded in our tech culture.
The first thing that comes to mind when we talk about automation is automated testing, automated deployment and anything software related. We do all of that and I will share a few examples later.
We indeed automate everything when that is feasible and needed as the process is repeatable. For instance, all our hiring pipelines are automated including automatic scheduling of meetings, automatic release of test scores between systems, notifications, and more. Why we do that? It saves us time and it is a mundane work that has no value to the process and people.
Will you consider automated claims processing via machine learning solutions an automation? We do. It makes us more efficient and helps our customer support and claims management team focus on the customer.
And I will not mention all the Slack bots we use to automate mundane work.
Luko’s teams automate everything related to testing. Good and repeatable test that is executed on local and/or test environment saves us time and increases our confidence that there are no issues.
- Escaped defects that affect the critical paths of our application and prevent our customers to get the job done are always reviewed and covered with e2e tests.
- All critical paths of the applications are always covered with e2e tests.
- Our target is +70% on unit test coverage.
- All automated tests are integrated in the CI/CD pipelines.
This will sound like common sense but we would like to emphasise it. The release process in all teams is fully automated. Every engineer has at least basic understanding of CI/CD and operations and we are proud that all teams own the development and production operations.
We also use tools that help us speed up our code reviews such as static code analysis tools and pre-commit tools. Everything that can provide instant and early feedback to an engineer about their code during implementation, we will put in place. It saves time and helps us avoid human error.
TL;DR; If one of our engineers comes across work that is repeatable, reproducible (and mundane), they will automate the process. There is no question about that!
Final words
Principles are meant to foster a particular culture and behaviour. A culture is not something static and evolves with every new person that joins a company. At Luko Engineering, we had our principles embedded into our DNA through the past years and with every new engineer we enhance them further by adding more of what we would like to have.
The engineering principles today will not be exactly the same tomorrow. We will continue to collect feedback from our team while it scales and add more practices under each principle with the growth of our business and organisation. We are open-minded and understand that with time, more principles might be added to reflect better our maturity and organisation. Certainly, with the evolution of our culture, we would like to keep being pragmatic, fast and impactful.
