Achieving rapid iteration to create better products

At Smarkets, we ship a lot. So much so that in our employee chillout area, a poster parodies our own ship-fast culture with an image of a burning ship. As we’ve grown, we’ve got better at it. Commits are smaller, more frequent and we release fresh code every day. From design through to release, we like to keep the cycle as short as possible.

The benefits of ‘rapid iteration’ are widely appreciated – it means more business agility and a better connection to customers. We get their feedback earlier, allowing us the flexibility to change direction with less wasted energy. In turn, customers notice the frequent small changes and are reassured that we’re working to make the product better.

So why do larger companies struggle to achieve rapid iteration? We certainly rely on good technology, but larger businesses with more developers and bigger budgets typically demonstrate too much inertia to do the same. It’s my belief that the key differences are not in the technology choices – the continuous integration, the provisioning and the hosting – but in the organisation itself.

The business needs certain ideals for rapid iteration to flourish, as follows:

Don’t seek perfection: Most engineers I’ve met are perfectionists. The idea of shipping a minimal viable feature is upsetting to them. They fear that once shipped, they’ll be told to move onto something else. If you convince them they will have more time to work on the feature after it is initially shipped, they’ll produce something more lightweight, faster.

Allow errors to happen: Reduce the price of failure. If it doesn’t work out, roll back, rethink and try again. Encourage a no-blame culture, which means staying calm if it doesn’t work as planned. Revert production to the last healthy state and carefully fix and test in development. Don’t encourage ‘superstar engineers’ who fix things in production late at night or at the weekends. People will be scared to ship often if they fear the consequences.

Give developers freedom: Rather than separately planning phases of development followed by refactoring, it is much more effective to improve things in an unmanaged fashion. To this end, when we do estimations, Smarkets assumes that only 50% of people’s time is on the planned work and the rest is for continuous refactoring and testing new ideas.

Trust: In some organisations, shipping a release requires multiple sign-offs from many managerial layers. The only solution is empowering people to take on that responsibility. Trust they will make sensible judgements about when to involve more senior personnel and give them the authority to make those decisions.

With this in mind, we have a relatively flat organisational model at Smarkets. Teams take collective responsibility for code they ship. Engineers review each other’s code and seek advice from colleagues on whether to ship, rather than chasing up a management chain.

Patience: The culmination of a piece of work at the end of a week often heightens the desire to ship it late in the day, or worse on a Friday evening. These behaviours lead to increased risk of a failure out of hours, which in turn has a high cost of failure and a reduction in trust. Define a clear set of rules about when to ship; there are always exceptions, but clearly define the rules.

The biggest barriers to successfully achieving rapid iteration are not issues of technology, but issues of people management. It may require organisational changes – a flatter management system, flexibility in planning and a cultural shift. Allow errors to happen, fail fast and roll back without drama. Empower employees more and build trust with them. Not only will it foster rapid iteration, but it will also mean a happier workforce.

Tim Gee leads web and mobile application development at betting exchange Smarkets. Before joining the company in 2016, he spent over a decade in several top-tier consulting and investment firms, including PwC, Credit Suisse, Lehman Brothers and G-Research.