You remember how engineering students talk about business majors. The jokes are a team sport. "Group projects." "PowerPoints." "Networking." You say it with the smug relief of someone who survived thermo and earned the right to look down.
Then you graduate and your week becomes their week. See Reason #9. You are not designing a machine. You are herding a schedule. You are aligning stakeholders, routing approvals, updating trackers, and polishing a deck that exists to make yesterday's decision look inevitable. The work that moves is the paperwork, and the paperwork is what you ship. See Reason #33.
The research confirms the joke. A widely cited time study of design engineers found they spend 28 percent of their time on problem-solving and the rest on documentation, consulting, planning, negotiation, and information gathering (Crabtree et al., 1993). A more rigorous follow-up tracked 78 engineers for 20 working days and found that 55.75 percent of their time went to information behaviors alone, seeking it, receiving it, or providing it to someone else (Robinson, 2010). This is not a secret. Domenico Grasso, now the interim president of the University of Michigan, wrote in the Chronicle of Higher Education that engineering curricula still train students as if the job were "solving problems through the application of math and science," while the actual practice has outgrown that model entirely (Grasso and Martinelli, 2007). His later book, co-edited with contributors from the National Academy of Engineering, MITRE, Lockheed Martin, and IBM, described engineering education as built on "curriculum models developed for early 20th century manufacturing and machining" (Grasso and Burkins, 2010). The people who run engineering schools know the job is coordination. They just have not updated the sales pitch.
Mechanical just adds a special penalty: the moment something gets real, you inherit the mess. A test pops. A fitting weeps. A bracket sings at one speed only. The install "doesn't match the drawing" because the drawing never met the install. Purchasing picked the vendor. Sales picked the date. Manufacturing picked the shortcut. Management picked the headcount. But when the hardware fails, it becomes "an engineering problem," which means it becomes your problem. You spend the morning writing the story and the afternoon cleaning up the consequences, with your fingernails paying rent either way.
This is what a mature field does to you. The exciting choices are upstream and already locked. You inherit integration, tolerance, compliance, cost, and risk, repeated on platforms that are "proven" right up until they are not. You become a custodian of other people's decisions. See Reason #14. The day-to-day is mind-numbing because it is designed to be auditable, not satisfying. See Reason #26. The center of the discipline barely moves, but the bureaucracy around it grows like mold. See Reason #35.
And if you actually wanted to be close to the hardware, hands on, solving the real problems, you probably should have gone MET. In most plants, that is where the practical troubleshooting lives, where you get credit for the fix, and where your skill set compounds into competence that travels well to other sites and becomes very hard to replace at your own. Meanwhile the ME title often buys you the privilege of being the paperwork wrapper around the people doing the physical work. See Reason #16. You can call that "engineering leadership" if you need to sleep.
The final insult is that once your job becomes packets, portals, checklists, and closeouts, it becomes portable. Then it becomes outsourced or it becomes scripted. See Reason #40. You mocked business majors, then you did their job, and you still ended up in the corner of the plant wiping somebody else's decision off a failing assembly.
References:
Crabtree, R. A., Baid, N. K., & Fox, M. S. (1993). Where design engineers spend/waste their time. AAAI Technical Report WS-93-07, AI in Collaborative Design Workshop, 209-219.
Robinson, M. A. (2010). An empirical analysis of engineers' information behaviors. Journal of the American Society for Information Science and Technology, 61(4), 640-658.
Grasso, D., & Martinelli, D. (2007). Holistic engineering. Chronicle of Higher Education, 53(28), B8-B9. https://www.chronicle.com/article/holistic-engineering/
Grasso, D., & Burkins, M. B. (Eds.). (2010). Holistic engineering education: Beyond technology. Springer. https://doi.org/10.1007/978-1-4419-1393-7
No comments:
Post a Comment