Before we begin, there’s something you should know about me. I love cheese and Branston sandwiches. This love of Branston pickle — a delicious, dark, unctuous, tangy turnip marmalade, means that I like to buy big jars of it. Really big jars. I even started my own business just so I could join Costco to buy their ENORMOUS jars, the ones that are the size of buckets.
It’s also important for you to know that I live in a small flat in West London, with a tiny kitchen and packed kitchen cupboards. I don’t have room for big jars of Branston — they make my cupboards completely useless, obscuring every other ingredient behind their massive girth. But it’s OK, because buying in bulk gets me the cheapest cost per ounce and the best economies of scale.
On a seemingly unrelated note, interest in so called “design thinking” has boomed over the last few years. IDEO — the company that designed the first Apple mouse — is largely responsible for its recent surge in popularity, but it’s also gained traction at companies like Google Ventures, Intuit and design agencies across the world over the last decade. In reality ‘design thinking’ is not new, and Tim, in his references to Isambard Kingdom Brunel, the great engineer and architect, makes no pretence that it is.
Tim references a 1960s definition of design, ‘change from current to a desired state’. This sounds suspiciously like the Japanese word made famous by Toyota, ‘kaizen’. Translated, kaizen means literally ‘change for the better’.
Toyota rigorously train their staff in kaizen problem solving. I was privileged to visit the Toyota factory in Burnaston, near Derby, where we were told of a problem they had with the overhead rails, on which deliveries of parts ran to workers on the production line. Small hoppers ran around the rails, like cars on a Scalextric track. In the course of a week, the rails built up carbon deposits, and the line would have to stop while they were cleaned.
On a production line, you do everything you can to make sure that the line doesn’t stop. But instead of a crack team of efficiency engineers, it was one kaizen trained Derby native working on the line who came up with the brilliant idea of literally zip tying a portable vacuum to the delivery hopper, cleaning the rails continuously as the machines ran and preventing hours of expensive downtime. Not a special team of efficiency experts, but rather what MIT professor, and innovation luminary Eric von Hippel would call ‘user innovation’
In design thinking we’re encouraged to spend time observing and interacting with the end users as much as possible, creating what Stanford’s famous d.school calls ‘how might we…’ challenges. At Toyota, this has a different name, ‘Genchi Genbutsu’, which means “going to the place where value is created”.
Design thinking and Toyota’s lean — the historic inspiration for agile software development — are twins separated at birth. They are codified common sense, with a customer centric, problem solving mindset.
In software development, agile has already replaced more traditional ‘waterfall’ methodologies. But it’s in traditional IT, in the provision of software and tools to end users, that lean and design thinking can really make a difference now — in the age of the cloud and pervasive end user experiences. Here, some IT departments are still guilty of exactly those same waterfall traits. Big projects, long specifications, too little time spent watching where users experience pain and implementation cycles that are too long.
I’ve seen too many overprotective IT departments roll out systems where the procurement has been too heavily weighted for their own benefit — ease of administration, ease of integration, existing supplier relationships — and too little focus on the enormous benefits that could be offered to the end user, and therefore ultimately to the company’s bottom line.
But this isn’t just to complain about old fashioned IT. The lack of end user focus — of spending time in the Gemba — is also rife within business processes.
A few years ago, I was helping implement new HR and finance systems. While sitting with the HR team we were discussing a report that needed to be produced by the new system. In talking through the value of this report we discovered that it was only produced to be passed on to another team to repurpose into a second report. We then discovered that after about two hours of processing, each week, the recipient of the report didn’t even read it — but had just inherited it from his predecessor. Not a technology problem, but a process and communication problem.
Just as with big IT rollouts, executive boards cling to the detail practice of annual budgets, a tortuous and painful process for the organisation each year which, just like a big spec document, becomes nearly immediately out of date despite the best efforts of those involved in predicting the future. Often it is exactly this practice at board level, of artificially blending resource allocation with targeting and forecasting in 12 month cycles, that causes IT departments to defer helpful initiatives, or rush capital spending just to capitulate to the tyranny of budgets.
Over-optimisation at a departmental level and false deadlines prevent many organisations understanding the big picture, of optimising the whole system and benefiting their most important and costly asset — their staff. No lean practitioner or design thinker would ever have created the system of annual budgets as they exist today.
Design thinking can therefore be applied to business and technology problems just as it can be applied to grand innovations. Sir Tim Berners Lee solved his own problem of sharing content with academic peers when he created the world wide web. The developers of the online game Glitch, working remotely from each other in different offices, solved their own collaboration problems when they invented Slack. By encouraging end user innovation in our own enterprises, we can apply design thinking to our own problems in our own businesses
Design thinking teaches us to put ourselves in our users’ shoes and think divergently.
Lean focuses on the creation of value for real customers and to cut our inventory down — whether that be an inventory of widgets, or lines of software code, or comfortingly precise but entirely inaccurate budget forecasts.
Or Branston pickle.
I really don’t need those big jars of branston. I can’t fit anything else in the kitchen cupboard, and if I order the little jars, sometimes I’ll get to try a different sandwich filling.
Tim Brown, Taiichi Ohno and Isambard Kingdom Brunel would all agree.
Prefer to see the video version of this article? Here it is!
This story is published in The Startup, Medium’s largest entrepreneurship publication followed by 297,332+ people.
Subscribe to receive our top stories here.