Engineering operating principles
How we think, collaborate, and make engineering decisions
Over the past few years of building at AI Squared, we’ve spent a lot of time reflecting on how we want to build not just what we want to build. The result is a set of engineering operating principles that guide how we think, collaborate, design systems, and ship products.
These aren’t lofty slogans or management posters they’re the hard-earned lessons from scaling complex platforms, solving customer problems, and learning from both successes and mistakes. Most importantly, they’re principles we use every single day to make better decisions, move faster, and build software that truly serves our customers.
Open communication
We believe engineers learn more from each other. So, we use public channels for questions/discussion/notes, not 1-1 messages. This helps everyone feel empowered to share ideas and questions openly. It builds a culture where everyone learns, not just the person asking. For sensitive conversations or personal chats, we use direct messages on Slack.
We start from the problem, not the solution
AI squared engineers focus on the problem, on understanding it, and on finding a right solution that fits the current context. If we start from the solution, we end up fitting a solution to the wrong problem, and reducing our final impact.
Build what customers really need, not just what they say they want.
AI Squared operates in a field where our customers have used manual processes and legacy technology. It’s our job to show them a better way. So, when they have issues or ideas, we always look into them carefully before making anything.
Move fast in decisions you can undo; be careful with ones you cannot
Decisions like designing data synchronisation pipelines are very core to our platform , so it’s important to get them right the first time. But if you try to make everything perfect from the start and worry too much about every choice, you’ll end up moving too slowly.
At AI squared, we value speed, and strive to optimise for the simple now and the complex later. Always ask: is there a version of this that is quick but also extensible? If you can find one, you’ll be able to move fast now and also move fast later - the best of both worlds
See something say something
We deeply care about our product and customers. Ownership is individual. But when we see a bug or a risk, we raise it. If we see a system that is not behaving as expected, we notify the owner. The more we create this habit, the more awareness we have around what’s not working and owners can prioritise appropriately.
Break down projects into small, independent chunks
At AI Squared, when we write product specs or tech specs, we start by breaking down the ideas into the smallest parts. Then, we decide the importance of each part based on how much incremental value it adds and how hard it is to make. We should aim to identify which 20% of effort can deliver 80% of the results if possible.
Take small steps and deliver quickly
Work in small, clear steps. Stick to small meaningful pieces of work for each update and avoid adding extra bits at the last minute. Smaller changes are simpler for the team to review and safer to fix if something isn’t right. By rolling out features bit by bit at a fast pace, we can quickly learn from and help our customers.
Share for early feedback
Share early in the decision process to avoid “big revelations.” The more context people have, the better their decision making. Eg: sharing draft PR, draft documents, design mockups etc.
Document architecture and design decisions.
We write down our decisions as one pagers/technical specs to understand them better, help ourselves in the future, and teach others how we made them. Design documents let us learn from each other, get advice, and create better products. This way, we come up with better solutions by using the team’s shared knowledge.
Engineering must serve the product and customer
Our ultimate goal as engineers is to create value for our customers. We understand that software development is not an end in itself but a means to serve the needs of our users. We align our engineering efforts with the product vision and business goals by developing a deep empathy for our customers
Many of these ideas were inspired by engineering cultures we deeply admire like Ramp’s emphasis on clarity and speed, and Slack’s commitment to openness and thoughtful communication.