BUILDING BRIDGES – In this new series, people from startup studio M33 discuss their relationship with lean thinking and how the methodology helps them in their daily work.

Words: Marek Kalnik, CTO and Co-founder of BAM

I recently visited the Toyota Commemorative Museum of Industry and Technology in Nagoya. I was particularly impressed by the machinery on display in the Textile Pavilion, which tells the great story of how the automation of Toyota’s original wooden hand looms ended up transforming an entire industry.

While walking around the exhibition room, I couldn’t help but ask myself what I – a software developer – could learn from the way Sakichi Toyoda improved those first looms. Are there any lessons I can take from Toyota’s history and apply to my work? There are, of course! Let me give you an example.

During a recent gemba walk, I was working with a team that needed to improve its productivity. In particular, I was observing one developer who was executing a common and necessary task: fetching data to write code for the different components of the mobile App he was designing. I noticed that at one point he was creating an interface element (what we call a “component” of an App) by:

• creating a blank file for the component;

• opening a random component in the App;

• copying and pasting the existing code into the newly-created empty file;

• and, finally, modifying and cleaning up the pasted code to create the component he needed.

The ideal process would have been to create a new file and add the necessary lines of code. When I asked the developer why he did it that way, he told me that it was the most convenient way. “The code I need is standard, but quite verbose. Copying saves me from having to remember it and helps me to avoid errors,” he explained.

In my eyes, however, it was waste: there were a lot of unnecessary movements and actions that were severely impacting his efficiency. The developer had come up with a solution to bypass his problem, but that didn’t appear to do anything to improve the process. Inspired by Toyoda's hand looms, I asked myself how we could automate the task.

It turned out there already was a solution to this problem: code snippets (configurable code fragments that help to generate commonly used components). The developer and I agreed to give them a try.

A few days later, I was back at his work station and I asked him what had changed since he introduced the snippets. He answered: “I reconfigured my working environment last weekend and snippets were one of the first things I added. They are really convenient! They only save up a few minutes every day, but their real value lies in the fact that they allow me to stay focused. It helps me stay in the flow and avoid distractions.”

So, I think there is a lot that we as software developers can learn from weaving looms. The first invention Sakichi Toyoda patented was the wooden hand loom. After observing the work of operators, however, Sakichi realized that breaking the process in chunks and automating them would bring huge benefits to workers. He achieved great results by approaching the process with a clear intent: making the operator’s job easier.

There is no doubt the same applies to software development. It is a technical leader’s role to ask himself what the pain points for developers are. This will result in improvements that will hugely benefit people at the front line, and by making them more productive the company as a whole will benefit, too. Personally, I think the most important lesson from the looms story is that purpose is the most important part of a “go see” exercise: you need to know what you are looking for, and what outcome you want to achieve. In my mind, that outcome should be finding ever better ways of working for front-line people.

_{THE AUTHOR}