An idea worth stealing

Watching how software engineers work could revolutionise how we build products and services, and give employees more interesting and fulfilling work. Edward Lowe talks Tesla, Henry Ford and a lesson from the slaughterhouse

In 2011, venture capitalist Marc Andressen wrote just how profoundly the software revolution would industries and changing the way we interact with a range of products and services. However, what is not talked about is the second revolution from the software industry - a very different way of thinking about building products and software. I think this revolution could be as important as the software revolution itself.

When Ford became the superpower in the automotive industry with the development of the Model T in 1908, it was driven by a revolution in the way that companies make cars. Borrowing from the slaughterhouses, Henry Ford set up a production line, dividing the labour into simple tasks. This allowed him to sell at a fraction of the cost of competitors. Fast forward to the current electric car revolution, and Tesla’s use of software engineering methods to find and fix problems fast, iterate on their software (using ‘agile’ programs to continually learn and adapt), and develop new ideas, has led them to overtaking all competitors to be the largest EV automotive maker in the world.

Luckily, existing companies can learn how to build products like the hottest startups in the world. Here are the methods that help these companies build great products and services.

Feedback loops during building

The first key insight, formalised by Eric Reis in Lean Startup, is to frequently gather feedback from customers about what you are building. Rather than wait until products are built, software companies build the minimum viable product that could help test their assumptions about whether the product would be valuable or not, and then find a way to get it in the hands of customers. This ensures we collect feedback and build this into the product, increasing the chances that what is built is useful and won't waste our development time. This is a key change to the traditional approach of the product on the market being the final version. Instead, the product on the market is the first version, which will improve over time. For example, when you buy an iPhone, the software will continue to improve as new versions of the operating system are rolled out.

The team improves its own processes

Traditionally, efforts to improve the effectiveness and the efficiency of teams have been driven by leadership – those leaders implementing projects that they believe will improve the team’s ability to deliver quality products. But how do they know what is useful to change? Often this is driven by their own agendas, and not by what the teams need.

In software development companies, teams are free to choose which ways of working benefit them. More importantly, they are empowered to change these at any time. Teams run retrospective analyses, in which they review their effectiveness and suggest improvements. They are free to implement changes themselves. This makes working in teams more enjoyable for employees, and stops a company’s standard ways of working getting in the way of the teams trying to do the work.

Cross-functionally organised

Another key insight from software engineering is to put all the skillsets together you need in order to deliver a valuable product. In the context of software engineering, this means having software engineers, product designers, product managers, delivery managers, and quality automation all within the same team, working together on a daily basis.

This avoids costly handovers between departments during the development process, in order to handle different elements of the process, instead meaning the team can go from idea to production with no external help. Companies can think about re-organising around the key question of 'Who do we need to be able to define, build and release this product?’ They then put all of those in the same team. Organising teams this way can unlock quick value creation.

DevOps

Software engineers are obsessed with making it as easy as possible to move the product into the hands of customers. Removing toil around releasing to production allows for teams to be able to release more frequently, and spend less effort to do so. This applies to physical products as well – think about the amount of time to set up a new physical store, or speed to get a new product into stores. Obsessing over these details like software engineers can help organisations move considerably faster. Once the time to release reduces, teams can ship smaller numbers, helping to implement the critical feedback loops.

While software continues to revolutionise all organisations in the private and public sectors, there is an untapped opportunity for organisations to learn the lessons of how software is built in order to deliver more valuable products and services for their customers. Taking a leaf from their books could be the next revolution in the way that we all work.

Edward Lowe works with software teams to build products for customers using agile principles. He is currently Lead Agile Delivery Manager at UK Healthtech startup Babylon Health.