You are here
Latest Posts
-
May
08
2013
RIPE Atlas probes hosted by EU Edge
Continue... -
May
08
2013
We are Atlassian experts
Continue...
Apr
04
2008
Engineers vs. managers - the trap of perfectionism
Now is the second time, that the fundamental difference and source of all major conflict between an engineers and managers approach is revealed to me as I'm reading Kaizen and The Art of Creative Thinking by Shigeo Shingo: engineers, they want to 'fix' problems, while for managers, it's sufficient to 'manage' them - that is, have them under control. The first time I encountered this comparison was reading The Hacker's Diet by AutoDesk founder John Walker.
The solution, as most of the time, is in between.
Faced with an issue, engineers, having a perfectionist stance, deem any 'solution' a failure, unless it is a 100% solution. If the tap is leaking, the only solution is such that there are no droplets coming from it if it is closed. Whereas for managers, the goal is to keep the issue at bay, and know how to maintain a status quo. Using this approach, placing a glass under the tap, and making sure it is emptied regularly is solution in itself. After all: there's no unknown leakage anymore, and everything is kept under control.
Of course, the best usually comes when these worlds are combined: let's improve on the valve, so that dripping is very limited, but still place and empty the glass underneath, albeit emptying with much less frequency - something that would not be considered a solution by an engineer at all. But from a managerial perspective, the maintenance resources are decreased considerably, and thus this is a major improvement in itself.
Shigeo Shingo suggests that this is actually a very good way to eventually achieve a 'perfect' solution, as it is easier to tackle only parts of a problem than the whole. One can 'solve' say 60-80% of the cases with a naive approach, and put it into effect right away, already harvesting the benefits. And then there's time to go for the remaining 20-40% later.
To the frustration of perfectionist engineers, this latter improvement sometimes never happens, and then there's a feeling that 'everything is broken', 'nothing is done properly'. And from his perspective, this view is understandable. But then again, making 60-80% improvements on other parts of the process is most probably a time much better spent than attacking 20-40% yields for the sake of perfectionism.
Nevertheless, the source of the conflict is ever there, and one must be wise to mitigate it regularly.
Comments
There is sure a huge mismatch between the thinking of manager and the engineer types, but this stereotype about the engineers being all perfectionist is a bit flawed I think. Engineering actually teaches that you have to aim for the good enough solutions, not the perfect ones. Unless the perfect one is the only one good enough, of course.
The ones who are expected to always go for perfect, the theoretically perfect solutions are the scientists, the theoretical guys. Actually if someone looks for the great engineering examples (like of course the various space missions) they are all about the good compromises.
So I don't think that it's that simple that engineers (and I mean real engineers with an engineering degree) are just pure perfectionists. The real problem might be that usually there is a mismatch between a good enough solution from the engineering point of view and a good enough solution from the business point of view.
To illustrate it on your example, the theoretically correct solution would be to install a perfect valve, to improve it until it is not dipping at all. The managerial solution is to put a glass or bucket under it and have someone empty it every know and then. The engineering approach could be to install a plastic pipe that takes the dipping water to the drain. You could call that hacking as well :) (Of course both the engineers and the managers would improve on the valve as much as it's sane.)
Yes, we might be using a different term for 'engineer' - as I'm in the software business, I'm referring to software engineers, who, usually, have a scientific degree (Master of Science), instead of an engineering degree. And as you point out well, this might be one of the reasons for their perfectionism.
Have any of you heard of the new academic field of study called service science, which is being heavily funded by companies such as IBM?
It's aim, among many other things is to break down tradition work silos and create cross function systems which incorperate, scientists, management and engineers to create innovation and value?
What are your thoughts on this? I am going to be doing my dissertation on this topic?
I think we all fail to realize one very important thing. Managers without their trickery, foolishness, hypocrisy and politics is nothing, it would not even be a field if it is'nt for these things.
A simple fact: Engineers can do a managers job at any time, whereas managers cant even dream of doing an engineers job.
Management is all about waffle, the more elegantly and professionally you can BS, the more successful manager you will be. Whereas the engineer is the one who is actually the one creating the product on which the company even exists.
I have to agree to Zeeshan. Managers are bureaucratic people that make development process difficult. You want to help solve client problems as quick as possible instead they make you stick to protocols they even can not fully understand and explain.They do not produce or increase any value in a company instead they will sit in a meeting taking meticulously notes about things they can not comprehend.When hiring a manager ask yourself this: do you want a creative,productive or a police state environment?
zeeshan & Lee: your words speak for a lack of expertise & insight into team work :)
Akos:
If you are talking about a technical manager yes there is team work. But there is no such thing with non-technical ones. All they care are the milestones one to many times against quality. They usually don't care / understand the problems a project is facing.
All I stated above are valid - talking from my own work experience as a SW Engineer.
while I understand that this might be your personal experience, this might only mean that you've had bad luck so far in working with bad managers.
moreover, as stated in my original article, your point of 'bad quality' might not be a valid point from the managers perspective. as you see, a lot of times 'good enough' is really good enough - or the best, actually, in terms of costs and customer satisfaction.
it's just that the perspective is different.
if it was your task to optimize along the lines of effort (costs) vs. satisfying a real-world customer need, as opposed to optimizing code for speed or size, for example, your take would be different too.
Add new comment