Or...how we get sh*t done.

Why do we need engineering principles?

Principles aren’t rules. A rule is something you have to do. A principle is something you should do for the good of everyone else, like brushing your teeth.

Our engineering principles are a set of agreements about how we work together. They enable us to work smoothly as a group, to improve our collective performance, and give us more bandwidth to focus on product and delivery.

Along with our growth framework, our principles give us a roadmap on how to have a thriving and meaningful career as an engineer at Cleo. They also help inform our craft and serve as a tool for decision making. (Unless, you’re just the type of person who loves having too many meetings?)

Our principles

First off, we feel that any principles need to be simple-to-express and simple-to-understand. They should capture the essence of what it means to be a product engineer at Cleo as efficiently as possible.

There are many different approaches to expressing engineering principles. Ours are grounded in our company values, specifically  “iterate with data.”  All our principles ladder up to this ideal in some form or another.

Do the simple thing

We don’t build software for the sake of software. We build software that delivers value for our users whether they are our customers, employees or other stakeholders. We don’t argue endlessly. We make small changes that deliver business value quickly and test these with our users to get feedback quickly. We resist the urge to over-engineer or add just-one-more-feature. We let our users and the data tell us where we go next.

We innovate in our product, not our tech stack

We choose technologies that allow us to make an impact, full stop. We love being boring. We love to choose well-worn tech. We don’t chase shiny fads. If we do choose to innovate in our tech stack, or choose newer frameworks or technologies it is because they have a clearly identifiable value to our users and to our business. What really matters is that the tech works and is valuable and useful and accessible, not whether it is new or old.

Technical debt is useful

The deliberate, conscious and careful accumulation of tech debt is a powerful tool that lets us ship code and value to our users faster. We are not afraid of it and we know we need to repay it over time to avoid the interest becoming unbearable.

We are considerate coders

We acknowledge that others will need to modify our code. We write code to be read by humans, debugged by humans and maintained by humans. We distill complex problems into code that is concise and easy to follow. We favour platforms, tools and libraries that are easy to understand and have good introspection tools. We don’t swallow critical errors silently. We use comments and commit messages to explain the *why* as well as the *what*.

We help each other

The output of the team is more important than the output of any individual in that team. We review each others’ code and give each other useful, constructive feedback for any significant changes. We learn the best and quickest by giving and receiving feedback early and quickly from each other. If someone is stuck, helping them is the highest-value use of our time: spreading knowledge and skills levels everyone up. If someone is waiting for a code review, we prioritise that ahead of writing new code for ourselves.

Our principles don’t stand alone. Together they are greater than the sum of each individual principle and should be considered as a whole. In line with our value, this is a living set of principles which we will continue to explore, discuss and iterate.


Like everything we do, these are a work in progress. What have we missed?  How would you see them change?

And of course, if these principles resonate with you and Cleo is the type of place you’d like to build your career, then head on over to our careers page and have a look at our open roles.

Even if you don’t see something that matches your exact skills, if you’re passionate about code and our mission, then we’d love to talk regardless.