Some industries have a long history of doubling down on business process optimisation. The goal is usually to save money by reducing working capital or increasing throughput to meet production needs.
This has been most obvious in manufacturing over the last 30 years. Optimisation in manufacturing has brought us lean systems, Just-In-Time, pull systems, Kanban, Kaizen and others. Innovation and change have been so intense that many manufacturing environments are now home to more robots than humans.
Manufacturers protect every second of time and every dollar of raw materials to keep cash off the production line.
The same is not true in all business environments.
In 1967 Melvin Conway observed that “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” This rule (known as Conway’s Law) is more visible now than ever, and applies to business processes as much as to technology systems.
Look at your own company and ask yourself what steps are required for a simple process. Perhaps you’ll look at hiring and onboarding a new employee, or processing a sales lead to close – you’ll probably notice there are far more steps than you’d realised. You’ll see hand-offs and checkpoints between different teams, which are there in theory to add rigour to the process, but which in fact often serve more as a barrier to communication and understanding, with each inter-departmental step becoming a process step in its own right.
Musk’s 5-point strategy
Elon Musk isn’t the most eloquent of speakers (and certainly doesn’t always show the behaviours of a model citizen). But he does an excellent job of focussing on specific quirks of human behaviour and applying those observations in his business strategies.
In his recent Starbase tour with Tim Dodd, Musk outlines the five-point strategy devised at SpaceX to encourage all team members to question and optimise their own business processes. In his trademark rambling style, he singles out some common behaviours humans display in the enterprise environment and suggests ways to challenge those which aren’t beneficial or which might even be damaging.
1. Make your requirements “less dumb” (Musk’s word, not mine).
Musk believes that the requirements will be “dumb”, no matter where they came from. They’re even more dangerous if you rate highly the person who gave them to you, as you might not question them.
2. Try to delete the part or process.
If you’re not occasionally adding things back in, you’re not deleting enough. Most people will add steps rather than take them away, ‘just in case’. Musk talks about asking a person, not a department – if a requirement or constraint has someone’s name against it, it’s more likely to be needed.
3. Simplify or optimise.
Optimisation is Musk’s third step (not his first) because, as he sees it, it’s the most common error of a smart engineer to optimise a thing that shouldn’t exist. Musk believes that traditional schooling teaches us to answer a question without challenging the question itself, which means we end up with things that shouldn’t exist. Don’t end up optimising something that should be deleted. Simplify requirements, remove as many steps as possible, and only then look at optimisation.
Taiichi Ohno also highlighted this in his book, Workplace Management (Productivity Press, 1988). Ohno said, “Do kaizen to the manual work first. Once you know how to make more improvements, but the machine is preventing this, then you can look at the right machine that will further improve productivity and quality”.
4. Accelerate cycle time.
Musk tells us to “Go faster!” but not until we’ve done the first three things. The first three stages are crucial to get right because, as Musk says, “if you’re are digging your grave, don’t dig faster.”
I interpret this as meaning: if you don’t know how fast you can go, it’s hard to tell the proportional improvement offered by the next step (automation).
5. Automate.
Only automate your processes once you’ve completed steps 1-4. It makes no sense to automate a process that shouldn’t exist, which doesn’t make sense, or which hasn’t been optimised at the manual level first.
These are all common mistakes
I see these situations all the time in software development, starting with requirements that shouldn’t be there. Sometimes, we write requirements, not because they enhance customer experience (or reduce cost or complexity) but to fit a corporate myth about how departments should interact.
Look around you for process steps that should never exist.
On a recent project, a client’s QA team were drowning in admin and documentation – well beyond what would be considered ‘normal’, appropriate, or even practicable. As a result, their entire project was running several weeks late and projected to arrive at least six months behind schedule – almost entirely because of this bottleneck.
The solution mooted was to throw more QA people at the problem. We advised them to overhaul their approach completely, removing manual steps and simplifying their processes. The result was an overnight doubling of throughput without any additional cost.
Even Tesla has made these mistakes.
Musk tells a story of the disastrous production issues faced on the manufacturing line of the Model 3 Tesla in 2020. He slept in the factory and spent weeks trying to optimise processes that never should have existed in the first place.
When he finally stopped to question why one particularly problematic component existed, two different departments pointed at each other, and Musk soon realised that the part had no real purpose within the vehicle.
It should never have existed in the first place.
