An important attribute for any IT department is a kaizen（改善）mindset. Meaning “Good Improvement”, kaizen comes to business from Lean manufacturing, where it is a tool used to constantly look for better, more optimized ways of doing things. The quintessential kaizen story goes something like this:
A shipping line worker in a warehouse realizes that putting the most popular and frequently bought items on the shelves closest to the front will save time on boxing. He tells his supervisor his idea and they change things up on the giant shelves. They time the workers with the new set up and find out that sure enough, the average time to pick and pack a single box drops by 30 seconds. That saves the company about 8 cents a box, which is a tiny, tiny amount. However, the company ships out 500,000 boxes a year, so the annual savings are $40,000.
Kaizens show an investment in the company. The best workers care about what they are doing and how well they do it. Kaizens are also a way to build investment in a company. The more a person feels like they can change their environment, like they will have a positive impact, the happier and more productive they will be.
Kaizen is a daily activity whose purpose goes beyond improvement. It is also a process that when done correctly humanizes the workplace, eliminates hard work (both mental and physical), teaches people how to do rapid experiments using the scientific method, and how to learn to see and eliminate waste in business processes.
In other words: The more you care about something the more you take care of it. The reverse is also true.
Some companies have a hard time getting their employees to understand the improvement mentality, but one group that excels at it, (stereotypically speaking) is IT. A good developer is always hungry to write a faster function, a good designer is constantly on the lookout for a more effective layout, and good sys admin is always comparing hardware performance.
You have to document kaizens to make them an effective tool for progress. To keep that part of it from getting in the way, there are only 4 simple steps we follow in the documentation.
1) What was the problem? Be specific. Ex 1. “Function findByFoobar() is taking 20 seconds to run” | Ex 2. “Users keep misspelling the state in the address form”
2) What is the change? Ex 1. “Added an index to the foobar column” | Ex 2. “Changed the field to a select box”
3) What is the new standard and the benefit? Ex 1. “The function now runs in 1 second. In a month that reduces average wait times by an hour per user” | Ex 2. “No mistakes in the last week. Saved 3 hours in validating state names”
4) Who did you tell? Ex 1. “The IT team and the IT manager.” | Ex 2. “The shipping team.”
This last step is important not to skip. First, changes should never be made in a vacuum. Second, it is crucial to celebrate and share success from kaizens. Don’t forget to involve people outside the IT department. They need to hear about your accomplishments too.
You probably noticed that the two examples weren’t big, groundbreaking improvements. This Kaizen mindset is what Jim Collins is talking about in his book Good to Great:
“We kept thinking we would find the “one big thing,” the miracle moment that defined breakthrough. We even pushed for it in our interviews. But… no matter how dramatic the end result, the good-to-great transformation never happened in one fell swoop. There was no single defining action, no grand program, no one killer innovation, no solitary lucky break, no wrenching revolution. Good to great comes about by a cumulative process — step by step, action by action, decision by decision, turn by turn of the flywheel — that adds up to sustained and spectacular results.”