When Your Product Teams Should Aim to be Inefficient – Part 2

Technology Solidifies Processes

Customer-facing technology allows us to serve a growing customer base whilst requiring less employee time. We are no longer talking to an Amazon ‘wizard’ every time we interact with Alexa, we are talking to a piece of software – a manual process that has been solidified into a piece of technology.

Likewise, employee-facing technology solidifies an internal process and offers efficiency – be it when organising meetings, giving and receiving feedback, or submitting expenses.

Whilst solidifying processes into software brings efficiency to processes by reducing manual effort, it also makes the processes less malleable – changing processes is no longer just a matter of updating written procedures and communicating to staff, but a software development project that may never be prioritised. We will suffer if we solidify a process that is ill-suited. We’ve seen this with some SAP implementations – the software sometimes becomes so difficult to change that the business has to shape how it operates around the software.

Let’s expand further on this:

The diagram above adds two additional layers at the base – behaviours and beliefs.

Behaviours are simply informal processes – things that naturally happen, even when the process is not written down. Think of this as what nascent processes look like in a small organisation: people have an unspoken agreement that expenses should be photographed and emailed to a particular colleague. This unspoken agreement becomes formalised and explicit as an organisation grows, to help ensure new people have sufficient context in which to operate.

What about beliefs? Beliefs are assumptions that guide our behaviour as individuals. In most organisations, they represent the beliefs of the founders and leaders – those that are first into the organisation and hold formal authority. They shape the organisational behaviours and processes, and therefore – indirectly – the technology.

For example, if founders hold beliefs in line with McGregor’s Theory X – the belief that people dislike work and will avoid it if they can – then their behaviour will generally focus on centralising control, supervising, and punishment. They will likely hire and promote people who hold similar beliefs, and over time the behaviours will become formalised as processes, and solidified into technology.

We will see quite different behaviours, processes and technology develop if founders instead hold beliefs in line with Theory Y – that people naturally want to do a good job.

An example of beliefs shaping technology is in enterprise travel booking software, inspired by The New Economics. If leaders believe that costs must be minimised and staff cannot be trusted, then they may add approvals for any significant expenditure. This may lead to a centralised financial approval process for travel, and eventually a software system so staff can more efficiently submit travel requests for approval.

Unfortunately, this tends to lead to unintended effects: booking travel takes more time and effort from all involved (form-filling, approvals, rejections, resubmissions). Staff are encouraged to seek cheaper flights, meaning meetings are missed or people arrive tired. There is an indirect and immeasurable impact to staff productivity, leading to costs to increase rather than decrease.

In response to costs increasing and staff grumblings, leaders may revisit the problem and reimplement the travel request and approval system – but to what end? Perhaps a few fields are removed, a bit of polish added – but fundamentally the same problems exist.

It is only when we re-examine our underlying beliefs can new behaviours, processes and technology emerge.

Let’s first recognise we can trust our staff. If we can’t, is our hiring process to blame? There will always be exceptions, but it is detrimental to everyone if we design our process against the few staff who may try to manipulate the process.

Secondly, let’s recognise that focusing on revenue will allow us to increase profitability with no ceiling, whereas reducing costs has a limit – zero, at which point we are out of business.

Perhaps our travel booking may be quite different – something reminiscent of what Reed Hasting describes in No Rules Rules:

At Netflix you don’t have to complete a purchase order and wait for approval to buy something. You just buy it, take a photo of the receipt, and submit it directly for reimbursement. But that doesn’t mean no one pays attention to what you spend. […] 

At the end of every month the finance team sends a link to each manager listing all receipts per employee for the previous weeks. The manager can click on those expenses and drill down to see what each person spent. […]

Usually after just one or two conversations clarifying context your employees will get the hang of how to spend the company’s money wisely and that will pretty much take care of it. When employees realise their managers are keeping an eye on expenses, they aren’t likely to test the limits much. […]

Some people will cheat, but the gains outweigh the losses.

We must recognise we would get limited success in mimicking behaviours, copying processes or replicating technologies from other companies. They would be rejected or implemented incorrectly if we do not first reexamine our underlying beliefs.

Before transforming technology we must first reexamine our beliefs.

Preventable Demand Indicates Ineffective Processes

The Vanguard Method divides work into two categories to help organisations understand where they are spending their limited resources:

• Value demand is work that directly contributes to the business objectives. This may be customers requesting a quote or placing an order.
• Preventable demand is avoidable work caused by a failure to do something, or failure to do something right for the customer. This could be customers contacting the call centre because they’ve received the wrong part, aren’t able to understand their bill, or complaining that the tradesmen has not turned up.

Preventable demand is named such as it can be eliminated altogether by upstream fixes: improving the order fulfilment and tradesmen scheduling process, and redesigning the bill to be intuitive to the customer.

In Beyond Command and Control, Professor John Seddon reminds us that “in financial services failure [preventable] demand frequently runs between 40% and 70% of the total, in utilities and public services 90% or even more.” The existence of so much preventable demand is a blessing and a curse. It is a curse that it exists and distracts us from the value demand that allows us to contribute to the business objectives. It is a blessing because, through upstream fixes, we can double our capacity or more – without the need for more staff.

Preventable demand signals we may have ineffective upstream processes and technology. Sometimes simple fixes are all that’s needed – such as refining processes to ensure the right part ends up with the right customer. Other times we may need to reevaluate our beliefs, about our staff or customers – such as who reads bills, and what is important to them?

I regret to admit as a young developer I created significant preventable demand for our development team, and for our customers. On one occasion, I released a software change that meant our trading team could no longer check the price of bonds. In doing so, not only did our development team have to handle complaints and provide prices manually (preventable demand), but traders could not handle their customer requests and had to spend time fielding complaints (more preventable demand).

I had solidified a broken process as software, requiring greater effort and coordination to fix than if it were simply a process, written down on a piece of paper. Whilst technology brings efficiency, it solidifies processes.

Whilst technology can help us be more efficient in handling value demand, rethinking upstream processes eradicate preventable demand and double our capacity for value demand.

Summary

As product teams, we should aim to be effective before efficient. During a discovery period it is okay – even preferable – to be inefficient in servicing customers. Our focus should be on learning.

Whilst solidifying processes into software features allows us to address more customer requests with less staff effort, it also then makes those processes harder to change. It is no longer just a matter of updating written procedures, but a software development project that may never be prioritised.

If we solidify an unsuitable process, it may lead to preventable demand. This preventable demand is most visible in call centres, and is a blessing and a curse: a curse that it exists, but a blessing in that, once removed, we have increased capacity without the cost of additional headcount.

Thinking of applying these concepts in your organisation, or want some guidance on how to get going? Reach out to us here for a chat.

Learning More

• Beyond Command and Control introduces the powerful concept of failure demand.
• The New Economics lays out new management principles for transformation.
• The Human Side of Enterprise reframes important beliefs for how we manage staff.
• Platform Engineering as a (Community) Service suggests how a solid platform can underpin and empower development teams to build great software.

This blog is written exclusively by the OpenCredo team. We do not accept external contributions.