The previous set of tech principles for the FT.com team were written in 2014 when we began building the new website and they prescribed a bold change of direction for the product and technology department. The old website was a hotchpotch of different technologies owned by different teams and changes often took several months of effort to reach our users.
The team tasked with building the new website was granted ownership of the whole stack in order to ship things quickly so we could experiment and learn with far less investment and risk.
Launching a brand new website is a goal which is easy to communicate and use to decide which tasks are important. This clear goal helped us to build momentum and the tech principles embodied the energy of this fast-paced and experimental phase of FT.com:
Optimised for speed to market
When new pieces of features are ready, they should start delivering business value immediately.
After the excitement of launching the new site in late 2016 we stumbled into a period we dubbed “the difficult teenage years”. Although we were shipping more code more often than ever a growing team was struggling to pull together under a new shared purpose and as colleagues moved around things started to drift.
As professional engineers we should consider the work needed to keep a codebase healthy and supportable as important as writing new code but when drifting it’s tempting to skip over details like keeping documentation up to date or writing good commit messages. Over time this makes our codebase less supportable and leads to more of the same.
As part of our technical strategy refresh for 2019 we chose to update our tech principles to better reflect the current environment and to apply them proactively to foster a more sustainable approach to shipping code.
Redefining the principles
We began by looking at what others do. Some of the tech principles published by other organisations were very high-level and included topics like budgeting whilst others defined micro aspects of coding style. By discussing these we started to get a feel for which kind would be applicable to our team.
Our principles are intended to help ~55 engineers split into several smaller project teams. Each project team is empowered to decide how they want to work and solve problems but the projects and outcomes they’re tasked with are governed by others.
With these considerations we decided that each tech principle should be:
- Purposeful and applicable to the real situations engineers face
- Empathetic to our colleagues, whether they are engineers or not
- Act as a guide rather than to be followed dogmatically
- Impermanent and to be revised in future
We added all of our ideas into an open Google Doc and shared specific drafts with the wider team in tech strategy updates to encourage discussions. Of course not every piece of feedback could be incorporated but we did our best to discuss any omissions face-to-face. After two draft rounds we reduced a long list of ideas — some respectfully copied from other orgs including Monzo, GDS, and Wikipedia — down to the following nine:
- Slow down to speed up
- Write code you can fix at 3AM
- Get to the root of the problem
- Make small changes often
- Keep things secure
- Favour existing solutions
- Use data effectively
- Treat unblocking others as your priority
- Assume good faith
To each principle we’ve added a short description and some questions we can ask to check whether or not we’re acting in the same spirit as the principle was intended.
Influencing the culture
Our previous set of principles were allowed to become obsolete in part because they were only recorded on a page deep within the engineering wiki that nobody looked at twice.
For our new principles to start influencing our engineering culture and be a statement of intent for others to see we needed to make them more visible. As well as publishing them in a public place and talking about them (in this blog post) we decided to decorate our (really nice) new office with them too. With the help of the design team we created a set of small posters that we can stick up anywhere:
To make our tech principles visible we created small posters we can stick up anywhere
The challenge for us now is to find effective ways to embed our new tech principles into day-to-day work. This might take the form of further creative such as stickers (because we all love stickers 💕), digital versions which can be used in code reviews, or some form of positive recognition for individuals and teams who stand out as having applied them well.
And to avoid our principles stagnating again all of the published documents are dated and I added a repeating entry to the team’s shared calendar to prompt us into reviewing them:
A repeating calendar entry should remind us to review the principles every so often
If our new tech principles sound appealing to you then you should come and join us: we’re hiring.
Special thanks to Caroline Handley, Ben Fletcher, and Luke Griffiths for all of the time and help they contributed to this project 🙇♂️