The System is Down...The System Is Down...
8.14.2006
I trained a bunch of engineering faculty this weekend, as mentioned in a previous post. Four out of the six people in the group are systems engineers, and they are designing and developing systems engineering courses for the online environment.
One of the struggles their incoming students face, they tell me, is that they all come from very specific engineering backgrounds: there are mechanical engineers, electrical engineers, mathematicians, physicists, etc. Each student enters the program having already worked in his or her respective field for years. As a result, he or she is well-used to thinking in certain processes. Any problem is approached instinctively from the perspective of his or her own field.
Trouble is, a systems engineer has to look at things as an interrelated whole, rather than a collection of disparate parts. When trying to troubleshoot systemic problems, then, it is extremely difficult for a longtime engineer to break out of his or her habitual thinking patterns and to focus on the system health as a whole.
What's more, when faced with the prospect of designing a system, it is excruciating for them to let go of the goal of designing the best components (something they would do in their respective fields); for in SE, the goal is to devise the cheapest, fastest, producible solution that achieves the client-determined performance standard. Whereas in a focused area of engineering the goal is quality, in SE the three salient factors are time, cost, and performance.
Breaking out of that "Quality is Job #1" mindset is terrifying, liberating and probably somewhat depressing at moments. You no longer think of your work as scaling the next mountain, or trying to hit the very center of the bullseye; you now think of yourself as the high jumper who would be foolish to expend energy jumping any higher than just above the bar.
It occurs to me that I am an area-specific engineer, and I work in a company that approaches education from a systems engineering perspective. My frustration with quality and stupid management stems from my failure to realize the difference in overall management priorities.
Cost, time, and performance. I think that's what matters, regardless of the product here.
For those of you who recognize this post's title, though: Enjoy!
One of the struggles their incoming students face, they tell me, is that they all come from very specific engineering backgrounds: there are mechanical engineers, electrical engineers, mathematicians, physicists, etc. Each student enters the program having already worked in his or her respective field for years. As a result, he or she is well-used to thinking in certain processes. Any problem is approached instinctively from the perspective of his or her own field.
Trouble is, a systems engineer has to look at things as an interrelated whole, rather than a collection of disparate parts. When trying to troubleshoot systemic problems, then, it is extremely difficult for a longtime engineer to break out of his or her habitual thinking patterns and to focus on the system health as a whole.
What's more, when faced with the prospect of designing a system, it is excruciating for them to let go of the goal of designing the best components (something they would do in their respective fields); for in SE, the goal is to devise the cheapest, fastest, producible solution that achieves the client-determined performance standard. Whereas in a focused area of engineering the goal is quality, in SE the three salient factors are time, cost, and performance.
Breaking out of that "Quality is Job #1" mindset is terrifying, liberating and probably somewhat depressing at moments. You no longer think of your work as scaling the next mountain, or trying to hit the very center of the bullseye; you now think of yourself as the high jumper who would be foolish to expend energy jumping any higher than just above the bar.
It occurs to me that I am an area-specific engineer, and I work in a company that approaches education from a systems engineering perspective. My frustration with quality and stupid management stems from my failure to realize the difference in overall management priorities.
Cost, time, and performance. I think that's what matters, regardless of the product here.
For those of you who recognize this post's title, though: Enjoy!
