A while ago I helped a team of developers with the database integration aspect of their project. How I love working at BigCo! As I worked, minding my own business, I couldn’t help but overhear a heated debate between the project manager and the head of development.
The project manager suggested something that seemed quite reckless, foolish even, and as far as the head of development, it was a no starter.
Developers seek Perfection
For the sake of an example, imagine a company manufacturing car brakes. Now, let’s assume that you are the engineer in charge of the new magnetic-hydraulic-brakes development team. These magnetic brakes are great, because they are more energy efficient, and they react faster. The drawback is that they need to be fitted differently in each car model for them to work.
What you’ve been doing for a while now, is running behind your sales team, calibrating and testing the system on every new model that sales thought was important. This is a long and time consuming process, and it is also quite expensive, because after you calculated the changes required for a car – you actually need a car for a test-drive.
After four months of hard work, the project manager comes into your office and says: “listen, this custom fitting and testing of the brakes is taking too long, and is too expensive. Also, we need to be able to fit these babies for next year’s models. We can’t ask Ford to send us a car that doesn’t exist yet! I want you to find a way to fit and test the brakes without having the car.”
You heard something different. You heard: “you are doing a bad job.” Blood is rushing in your ears. No, no, no, this is the only way to get accurate results. Not testing the brakes is just reckless. And dangerous. And stupid. You explain it to her, slowly, as if she was retarded. You are quite frustrated, because a good project manager would have understood this already.
In fact, the project manager knows exactly how and why you do what you do. She just doesn’t care.
Project Managers seek Compromise
She knows that if you can’t fit the brakes to next year’s models, the department will be terminated. She also knows that hardly any consumer upgrades the brakes on their car, so the brakes must be fitted for the factory line. She explains this. You state, again, that this is too dangerous. She says she doesn’t understand why you can’t simulate a car model. You explain, at great length, how you don’t have enough man power to write a simulation accurate enough.
Remember I’m still sitting there, in the corner, minding my own business? So I’m thinking: “gee-sh, why doesn’t she get it already.” But I’m not saying anything, and the project manager is pushing even harder for answers, drilling down the details of the No. She keeps saying, “I don’t understand why you can’t do it. How long will it take? Can’t you do a partial simulation? Can’t you use existing data and extrapolate missing points?”
Suddenly, a miracle occurs. Instead of calling her an idiot, one of her questions triggers something. You are quiet for a moment, and then you say that maybe – just maybe – you can use last year’s model and it will help do 50% of the calibration automatically. The conversation takes off. The two of you quickly go over the details, and with this new understanding, the project manager goes out to see if Ford can plan the new car given you will use last years fittings, and will finish the work with an early prototype.
Impossible is just very Improbable
I was amazed, and you should be too.
After months of working in a certain way, the development team started taking their assumptions for granted, mistaking them for facts. The project manager was able to force everybody to re-examine their assumptions. When put under heavy scrutiny, some of these assumptions were discovered to be irrelevant.
Don’t let the people you manage get too comfortable. It is your job, as manager, to push past what is considered possible today, questioning again and again the processes that you work by.
This is the Toyota Way
Toyota has a fifty years old tradition of self-inspection and self-improvement. This is how Toyota has become a leading car manufacture. You can see the 14 principles here.
- Become a learning organization through relentless reflection (hansei) and continuous improvement (kaizen).
The process of becoming a learning organization involves criticizing every aspect of what one does. The general problem solving technique to determine the root cause of a problem includes:
- Initial problem perception
- Clarify the problem
- Locate area/point of cause
- Investigate root cause (5 whys)
Always keep improving your organization.
(Sorry for the quality of the video)