Product Engineering Principles at Click Travel
Over the past year, the Click Travel Product Engineering team has grown to a team of over 50 people!
As we continue to grow, it’s crucial that we create a shared understanding of how to build good software. This is equally important for enabling our existing engineers in making decisions and prioritising work, and also for our incoming engineers in knowing what to expect and how we work.
So, at our last ‘Product Engineering Day’, we introduced a set of Product Engineering principles to help foster alignment and collaboration within our Product Engineering teams. We established that these principles should be taken as guidelines — not absolute rules that should be followed without pragmatism or thought.
Since we introduced these five Product Engineering principles, we have been pushing ourselves to share and refer to our principles a lot in our day to day (more on this in a bit). We also plan to review and update them every year or so, to ensure that they’re still guiding us to the results we want to achieve.
Our Product Engineering Principles:
Learn, Build, Measure (🔍,🧱,📏)
This principle has been inspired by ‘Build, Measure, Learn’ — a lean startup process made famous by Eric Ries. As we already have an established product, we want to start from ‘learn’ rather than build. We debated whether we should express this as ‘Hypothesise -> Experiment -> Test -> Insights’ but we felt that was too prescriptive as to exactly how to embody this practice.
Why?
To encourage and maximise validated learning about our product and how our customers respond to changes we make. We believe this approach will help us make more informed decisions about where to take our product, in order to achieve our vision of reducing the cost and complexity of business travel for everyone.
Why before how
This principle is designed to encourage us to start a piece of work by first deeply understanding the problem before writing code or ‘solutionising’. We believe that the success of any solution is based on fully understanding the problem that needs to be solved.
Why?
There are two core reasons for this:
- Rushing into the build without truly understanding why we’re doing something often ends up in a lot of re-work. None of us enjoy working really hard to deliver something, only to get feedback from the requester / customer that it doesn’t actually solve their problem and you need to start over. To avoid this, we need to be thinking up front.
- Often, it’s easy to get into a cycle of delivering the ‘very important person’s’ ideas before and above everything else. Most of the time, these ideas have no cohesion and are constantly changing, which makes it easy to veer off track from the company’s missions and objectives. Even if the idea comes from a very important person, we need to take time to understand the why in the request, to avoid wasting time building something of little value.
Our ask: Before starting to code, pause to evaluate whether the problem you’re being asked to solve is clear and valid. When coding consider how you or someone else may interpret your work in the future and how easy it is to understand, refactor, and remove.
Progress, not perfection
This principle was inspired by the fact we had just completed a huge transition project from a monolith codebase, to serverless microservices built in Node.js on AWS Lambda.
Due to the constraints of the transition project, we were delivering feature parity in ‘big bang’ style batches rather than incremental improvements. We wanted to get back to delivering work in small, meaningful pieces, by keeping pull requests small and focused, and ensuring work was getting put in front of customers as soon as viable. We are fortunate that we have the ability to push to production immediately — we want to get back to leveraging this!
Why?
We believe that fast feedback loops are important to successful, predictable and sustainable throughput.
Constructively challenge, debate, commit
Conflict, tension and debate are healthy as long as people focus on the ideas and issues, and not each other.
We want to encourage the team to constructively disagree and debate a decision whilst it’s being made, but once a decision has been made, everybody must commit to it, regardless of whether you agree or disagree. It also relates to the intent behind ‘Progress, not perfection’.
Why?
We believe following this approach will allow us to achieve faster customer feedback loops as we’ll be able to get things into production quicker if we don’t spend time in ‘analysis paralysis’ whilst trying to reach a consensus. The idea is that we want to encourage people to provide alternatives, rather than a straight disagreement.
Unblock others whenever you can
We can’t take credit for this one, we respectfully copied this directly from FT and Monzo! We believe this is incredibly important.
Why?
If someone is stuck, helping them is an incredibly high-value use of your time: spreading knowledge and skills levels everyone up. If someone is waiting on you for a code review, prioritise it ahead of writing new code yourself.
How did we come up with these principles?
I gathered my immediate team together (Robin — Chief Product Engineer, Hayley — Product Team Lead, Stuart — Head of Engineering Management, Golnaz — Head of Engineering Enablement) for a team off-site.
We ran through a “Be the kind of team you want to be a part of” exercise which we had learnt about in Julie Zhuo’s (@joulee) highly recommended ‘The Making of a Manager: What to do when everyone looks to you’ book.
This consisted of three parts:
- Understanding the current team (in our case, the Product Engineering department)
- Understanding our aspirations
- Understanding the difference
After understanding how we wanted Product Engineering to operate, we thought about what behaviours we would need to encourage in order to achieve that. After many post-it notes and a few iterations, the first set of our Product Engineering Principles were born!
Living the principles
When developing these principles, we were acutely aware that we didn’t want to spend time developing them and then find they gathered dust hidden on an internal wiki page somewhere. We want them to influence our Product Engineering culture and guide us in building a product that delights our customers.
Posters
As we’re a distributed team, putting up posters solely in our HQ in Birmingham wouldn’t cut it. Instead we put up large posters in the office, and then sent smaller versions of the posters to every distributed person to allow them to decorate their home offices!
Some people decided to have their posters placed behind them, so when they are on zoom calls, they become visible. Others chose to scatter them around the room — changing the placement every so often to keep them top of mind.
Slack
We created a dedicated slack channel for discussions about the principles, and a place for people to share photos of themselves with the principles.
We tried making a slack bot responder for each time someone mentioned one of the principles in slack, but quickly found that was driving the opposite behaviour — people stopped using the phrases in fear of the annoying bot response!
Some people have chosen to change their profile photo to show them holding a specific principle to subtly re-enforce them when chatting on slack.
Snippets
We use a ‘Weekly Snippets’ process as a mechanism to provide visibility to the entire department, and our stakeholders, capturing what impact each product engineering team has made, what they are blocked on, and what’s upcoming.
Each week, teams provide a written weekly summary in a dedicated slack channel, then we hold a short ‘snippets meeting’ where the Engineering Leads and Product Owners (and anyone else who fancies) come together to go through the highlights of the week (celebrations, blockers, advanced warning of upcoming items, overview of incidents).
We are experimenting with focusing on a single principle each week, and asking teams to capture in the written snippets and in the snippet meeting, how they have been living the principle that week, or what challenges they have faced when trying to live it.
The idea is to bring the principles into active conversation, so that becomes standard operating procedure. It’s also a way for teams to share knowledge and tips on how they have lived the principles in different ways, which we hope will help us avoid the trap of being overly prescriptive on how to operate and therefore missing the intent behind introducing these principles.
The next iteration
In the spirit of living the ‘Learn, Build, Measure’ principle — we’re in the process of measuring how effective our current approach of embedding these principles into our day-to-day work is, then we plan learn and iterate. We’re also still on the lookout to find other effective ways to influence our culture with them.
If this sounds appealing then come and join us — we’re always on the lookout for talented people to work with!
About the author
I’m an experienced technical leader who is passionate about technology and building high performing multi-functional teams to develop brilliant products.
When I’m not at work, you can find me on poolside coaching some brilliant Age Group swimmers at Edinburgh Synchronised Swimming Club!
