Reason #70: The Community Polices Itself

You would think that a professional community facing a documented oversupply problem would want to talk about it. You would think that engineers, people trained to read data and draw conclusions, would at least engage with the numbers before dismissing the person who posted them. That is not what happens. Post a sourced, detailed comment about mechanical engineering's structural problems on a mechanical engineering forum and the most likely outcome is not a counterargument. It is a removal (See Reason #39).

The pattern is predictable enough that you can set a clock by it. You write a substantive reply explaining that the field graduates far more engineers than the labor market absorbs (See Reason #1), that the Bureau of Labor Statistics projects flat or declining demand (See Reason #50), that one in five ME graduates ends up in a job that does not require the degree at all (See Reason #63). You cite the source. You link the federal data. Someone replies "sounds like you just had a bad employer." Someone else says "maybe engineering isn't for everyone." Then a gatekeeper removes the comment. Not because it violated a rule. Because it made the room uncomfortable and one of the rules was close enough to justify the click. No link was posted. No product was sold. The content was removed because of what it said, and the person who said it was permanently banned from two forums by the same gatekeeper on the same day.

Some of you reading this right now are learning for the first time that ME has the highest underemployment rate among the major engineering disciplines. You are learning it here because you were never going to learn it there. The forums where you would naturally ask "is this degree worth it" are the same forums where the answer gets deleted. The spaces where a first-year student posts "should I switch to EE" are the same spaces where the person with thirty years of experience and a sourced reply gets banned for self-promotion he did not commit. The pipeline does not just fail to warn you. It actively prevents other people from warning you (See Reason #25).

This is not an institutional policy. It is a community reflex. People who chose mechanical engineering and built careers around it have a stake in the narrative. They sat through the same thermodynamics sequence you did. They fought through the same job search. Admitting that the market is structurally oversaturated means admitting that the difficulty of the degree did not buy what they were told it would buy (See Reason #60). That is a hard thing to sit with. It is easier to call the messenger bitter and move on.

The suppression happens at every level. Online, forum gatekeepers remove posts and ban users whose only infraction was being specific. In departments, professors steer conversations away from labor market data and toward innovation narratives. At professional society events, the panel on "the future of mechanical engineering" never includes a slide showing that the field produces roughly two and a half graduates for every projected opening (See Reason #34). The New York Fed publishes it. The BLS publishes it. Nobody on the podium mentions it. And if someone in the audience brings it up, the panel chair moves to the next question (See Reason #59).

What makes this specific to mechanical engineering, and not just a general observation about groupthink, is the size of the gap between the field's self-image and its market position. Electrical engineering forums do not need to police criticism because their graduates are not underwater. Computer science forums do not need to delete comments about pay compression because pay compression is not their problem. The intensity of the suppression is proportional to the size of the thing being suppressed. ME has the largest graduating class, the flattest pay curve relative to difficulty, and the worst underemployment numbers in the engineering column. That combination produces a community that cannot afford to let the conversation happen.

A profession that was confident in its value would engage its critics. A profession that was honest about its challenges would surface the data and let prospective students decide for themselves. What you get instead is a profession that treats factual criticism the way a company treats a quality escape: contain it, document the containment, and make sure it does not reach the customer. You are the customer. And if you are reading this blog, it is probably because nobody in the places you looked first would let you see it.

Reason #69: The Seniors Who Trained You Won't Be Replaced

You learn mechanical engineering from someone who already knows it. Not from a textbook. Not from an SOP. From the person sitting ten feet away who tells you that the tolerance on that bore is tighter than the drawing says, because the last three builds chattered and nobody updated the print. That person is retiring in four years. Nobody is training a replacement.

This is how the pipeline dies. Not all at once. Quietly, over a hiring cycle or two. A company outsources the junior design work because it is "routine" and the offshore rate is a third of the loaded cost. The senior engineers keep their seats because they are the ones who check the outsourced output, catch the errors, and know which rules are real and which ones are artifacts of a drawing that has not been revised since 2009. Management looks at the org chart and sees savings. What they do not see is a missing generation (see Reason #25).

Junior work is not junior because it is easy. It is junior because it is where you learn what the senior people already know. You learn stack-ups by blowing one. You learn supplier tolerances by chasing a casting that came in hot. You learn test lab scheduling by watching your timeline collapse when the shaker is booked through Q3. You learn DFMEA not from the template but from the field return that nobody predicted. All of that requires being in the room, on the floor, next to someone who has already made the mistake you are about to make. The company will not teach you this. Your onboarding is a slideshow and a safety quiz (see Reason #54). The plant is the real classroom (see Reason #52). When you offshore that work, you do not just lose a task. You lose the classroom.

The senior engineers notice first. They spend more hours reviewing than creating. Their redlines multiply. The offshore team follows the procedure but misses the intent, so the senior rewrites the section, adds a note, and moves on. Then they rewrite another section. Then another. They become full-time editors of work they used to do themselves in half the time. They are needed, which in this field means they are being used until the cost of keeping them exceeds the cost of the errors they catch (see Reason #55). Nobody is learning from the corrections because the corrections go into an email thread that crosses nine time zones and ends with "noted, will update" (see Reason #12).

Five years in, the senior retires. The company posts the role. The job listing asks for fifteen years of experience in a niche that the company itself stopped teaching a decade ago. Nobody internal qualifies because nobody internal was developed. Nobody external qualifies at the salary offered because the people with that experience know what it is worth, and the company has spent a decade proving it will not pay accordingly (see Reason #27). The role stays open for eight months, gets downgraded to a "lead" title, and eventually gets filled by someone who checks the boxes on paper but has never touched the product. The field produces two and a half candidates for every opening (see Reason #34). None of them have fifteen years in a niche the company stopped cultivating a decade ago. The institutional knowledge is gone. It did not get outsourced. It got extinguished.

This is not a temporary gap. It is a permanent one. You cannot rebuild a ten-year development ladder by posting a req. You cannot buy judgment from a staffing agency. You cannot extract tribal knowledge from a retired engineer's email archive. The company burned the bridge while standing on it. The seniors who might have stayed were told the only way up was out of engineering entirely (see Reason #28), and now the procedures run without anyone who understands what they were written to protect.

You will enter this field and be told there is a shortage of experienced engineers. There is. The companies created it themselves.

Reason #68: AI Won't Replace Mechanical Engineers, It Will Replace What They Became

You will hear this at every conference and in every LinkedIn thread for the next decade: AI cannot replace real mechanical engineering. It cannot feel a tolerance stack go wrong. It cannot walk the floor and notice a fixture is drifting. It cannot sit across from a supplier and read the pause before the lie. All of that is true. None of it matters. Because the job you actually do every week is not that. See Reason #40.

You already read what the job became. You route ECOs through approval chains. You fill out DFMEA templates one failure mode at a time. You build DV/PV matrices in spreadsheets and track them in portals. You write test reports that exist to prove something passed, not to explain why it works. You chase RoHS and REACH certificates from suppliers who do not answer emails. You update BOMs in ERP systems that fight you. You reformat PDFs because a customer portal rejects embedded fonts. You paste screenshots into PowerPoint decks that a manager will skim for one bullet before asking for a risk line. See Reason #33 and See Reason #9.

That is the job. Not the brochure version. The calendar version. The version you live Monday through Friday, and often Saturdays as well. And every single item on that list is text-in, text-out work. It is structured, repetitive, and traceable, which is exactly the profile that large language models and workflow automation were built to eat. The question was never whether AI could replace a mechanical engineer who sizes a pressure vessel from first principles. The question is whether AI can fill out the paperwork that surrounds the pressure vessel after someone else already sized it. The answer is yes. It already can.

The compliance layer accelerates this. You spend increasing fractions of your week not designing but proving, assembling cert packs, mapping test evidence to requirements, building traceability matrices, and writing justification memos so an auditor can check a box. See Reason #51. That work expanded until it became the job. And it expanded into the exact shape of a task that automation handles well: collect inputs, apply rules, generate output, route for signature. You did not need to be replaced. You needed to be transcribed. See Reason #65.

The people who say "AI can't do what I do" are thinking of the 20% that still feels like engineering. The thermal intuition. The fixture hack that saved a build. The moment you overrode the model because you remembered a field return from 2016. That part is real, and no model replicates it today. But that 20% does not justify the headcount. The headcount was justified by the other 80%, the administrative throughput that kept gates moving, reports filed, and portals green. See Reason #42 and See Reason #26. When that 80% gets cheaper to automate than to staff, the headcount shrinks. You keep the title. You lose the seat.

This is not speculation. It is the same pattern that played out when admin work moved offshore, except faster and without the time zone lag. See Reason #40 already told you the rule: if the work can be written down, the work can be moved. Now it does not even need to move. It just needs a prompt.

The field will not vanish. Someone will still walk the floor. Someone will still argue with a casting vendor about why the draft angle cannot drop another half degree. But there will be fewer someones, and the ones who remain will be expected to carry the 20% that matters on a fraction of the old headcount, while a dashboard handles the rest. That is not survival. It is compression. And in a market that already has two and a half candidates for every opening, compression does not create opportunity. It removes it.

You were told your judgment makes you irreplaceable. It does. The job just stopped being about judgment a long time ago.

Reason #66: Your Personal Life Is an Employer Subsidy

You move for the job. You leave behind a person, a city, a proximity to family that you will not get back on this timeline. You do it because mechanical engineering is a physical discipline and the openings are where the plant is, not where your life is. See Reason #20. You tell yourself it is temporary. It is not temporary. The next role is in another plant town chosen by rail access and tax abatements, and the one after that is wherever your sub-specialty still has funding. See Reason #11.

Other engineering branches do not extract this. A software engineer negotiates remote before accepting the offer. An EE in chip design can work from a dozen metros with active semiconductor clusters, most of them places people actually want to live. A CS grad picks a coast and stays on it. You pick the job and the job picks your zip code, your commute, your weekend radius, and by extension, the pool of people you will meet, date, befriend, and rely on for the next several years.

The entry ramp makes it worse. The internships that qualify you for entry-level are in the same plant towns, on the same shift schedules, demanding the same uprooting. See Reason #57. You vanish for a summer, then vanish again for the first job. The people you left behind adjust to your absence. Some wait. Many do not. You learn this when the distance stops being a logistics problem and starts being a verdict.

Once you are there, the schedule finishes what the geography started. ME is remote-proof. See Reason #30. The test lab, the build floor, the shaker queue, the supplier visit, the 2 a.m. line-down call. Your availability is not flexible because the hardware is not flexible. Date nights get canceled for thermal soaks. Weekends get eaten by qualification runs that could not get chamber time during the week. You are not lazy. You are tethered. And the tether is shorter than your friends in other fields will ever understand, because their jobs do not live in a building that smells like coolant.

The social cost compounds quietly. You work in rooms that skew 8:1 male. See Reason #43. Your peer network is small, homogeneous, and geographically scattered across plant towns that do not overlap. The informal connections that other professionals build through mixed workplaces, urban density, and overlapping social circles do not form as easily when your office is a manufacturing campus thirty minutes from the nearest downtown. You make friends at work because work is where you are. Then you change jobs and the friends reset because the zip code resets.

None of this shows up on a pay stub. That is the point. It is an uncompensated extraction. The company gets your proximity, your flexibility, your weekends, and your willingness to relocate. You get a salary that already trails your engineering peers. See Reason #20. The gap between what you are paid and what the job actually costs you is filled by your relationships, your geography, your time, and your health. In economics that gap has a name. It is a subsidy. You are the one paying it.

The younger version of you does not see this. The offer letter looks like a beginning, not a trade. You are twenty-two or twenty-five and the move feels like ambition. You pack the car, sign the lease, and promise everyone it is temporary. Two and a half years later the company outsources the entire engineering department, and you are standing in a town you did not choose, missing a person you did not intend to lose, holding a resume that qualifies you to do it all over again somewhere else. See Reason #46.

The brochure calls it opportunity. Your twenties call it back and get voicemail.

Reason #65: Your Diligence Is the Blueprint for Your Replacement

They will ask you to write it all down. Not because they want to improve quality. Because they want to email it.

It starts with a reasonable request. Document your design process. Map your workflows. Write procedures for how you select bearings, size shafts, set tolerances, run thermal calcs, validate test fixtures. They call it ISO 9001. They call it quality management. They call it "institutional knowledge capture." You do it because it sounds responsible, and because your name goes on the document, and because you were raised to believe that good engineers leave clean records. See Reason #40.

Then the procedures leave the building. Not as training material for the new hire down the hall. As an attachment to a contract engineering firm in another time zone. Your step-by-step becomes their checklist. Your judgment calls become their dropdown menus. Your institutional knowledge, the kind that took you a decade to build and a week to type, becomes the onboarding packet for someone billing at a third of your rate (see Reason #24).

This is the trick. Nobody tells you during the documentation push that you are writing your own replacement manual. The language is always improvement. Standardization. Repeatability. Risk reduction. The moment the PDF is final and the revision block is signed, it belongs to the company. And the company has already decided what to do with it. You have no professional body that will intervene, no guild clause that limits how your work product is deployed (see Reason #13).

The problem is that a procedure is not understanding. You can write down that a stator vane needs a specific trailing-edge radius for a given pressure ratio. You cannot write down the twenty iterations that taught you why, or the field return that taught you what happens when someone rounds it. A checklist can be followed. A feedback loop cannot be shipped (see Reason #33). The offshore house follows step four because step four says so. You followed step four because you watched step three fail on a test stand in 2014. That gap does not show up until warranty claims start arriving, and by then the people who understood the gap have been let go or moved on.

Management knows this will happen. They have seen it before, at Boeing, at Enphase, at every aerospace OEM that hollowed out its engineering bench in the name of cost reduction. They do it anyway because the savings land this quarter and the warranty costs land three years from now, under someone else's budget, on someone else's watch (see Reason #23). When the quality collapses, the fix is not to bring the work back. The fix is to add more review layers on top of the outsourced work. More checklists to check the checklists. More of your time spent verifying someone else's output instead of producing your own.

You will be asked to document everything you know. You should understand why.

Reason #61: It's Business Administration, With Consequences

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

Reason #55: Being Needed Means Being Used (Until You’re Fired)

For a while, you will believe the place cannot run without you. You are the one who “makes it happen.” You translate vague leadership wishes into hardware that ships, you unstick the build when the pilot line stalls, you answer the questions nobody else can even parse. Then you remember the part they never say out loud. You are still replaceable. The market is still crowded. Your indispensableness does not make you unfirable. See Reason #34

Mechanical engineering is unusually good at turning you into a catch basin. Broadness gets sold as freedom, but in practice it makes you the default owner of anything that touches atoms. Demand modeling, supplier chasing, fixture triage, packaging drop test drama, “just run the numbers,” “just update the model,” “just make a quick drawing,” “just lead the meeting.” That is not leadership noticing your talent. That is the organization exploiting a job description with soft edges. See Reason #8

And because you are a cost code, not a revenue line, the gratitude is always temporary. Every new productivity hack comes with a new dashboard, a new cadence, and a new expectation that you can do two roles with one headcount. When the quarter tightens, your “range” is not rewarded. It is treated as proof you can absorb more. See Reason #23

Here is the darker part. Being the catch basin means you also become the blame basin. The more hats you wear, the more ways you can be “responsible” for something slipping. A supplier is late, a test slot is unavailable, a requirement changes, a VP wants it by Tuesday anyway. You write the memo, you own the action items, you stand in front of the slide with your name on it. In ME, visible impact is shared, but accountability sticks. See Reason #33

Those little dings add up. Missed dates you did not control. “Communication issues” when you refuse to promise miracles. “Not strategic” when you tell them physics has a schedule. Meanwhile your calendar is eaten alive by check-ins and “alignment,” which guarantees the work never gets a clean flow anyway. See Reason #42

Even your peers quietly benefit from it. If you are the fixer, everyone else gets to stay in their lane. Then review season comes and the lane-keepers look stable while you look messy. And in a field where everyone is competing for a small number of good seats, stability wins. See Reason #6

A naysayer will call indispensability a compliment. In a field with 2.5 credential holders for every working position, your indispensability is not a sign of your value. It is a sign of the organization running lean because it can (see Reason #1).

You will be proud to be depended on right up until the day they depend on you as the explanation.

Reason #54: Your Training Is a PowerPoint and Yelling

Your training will be a slide deck. If you’re lucky, it is recent. If you’re very lucky, someone actually walks through it with you. More often it is emailed, half out of date, and treated as proof that the company “did onboarding.”

After that, you’re live.

Mechanical engineering quietly assumes that competence appears through exposure. Not mentoring. Not instruction. Exposure. You inherit legacy drawings, old CAD habits, vendor quirks, undocumented PLC behavior, and a system that only works because the last person learned its moods the hard way. Then you are told to move quickly and not make mistakes.

When you do make mistakes, the response is rarely instructional. It is reactive. A raised voice. A “we already went over this.” A look that says you should have known. This is not really cruelty. It is the structure of the work. Senior engineers are rewarded for throughput and firefighting, not for building replacements. Teaching slows them down, so it does not happen. You are there to keep inherited systems running, not to understand them deeply or improve them thoughtfully. See Reason #14.

High turnover finishes what the incentives started. When people leave every two or three years, no one believes training will ever pay back. New hires are dropped into the deep end and told to swim. The pipeline quietly assumes apprenticeship, but the labor market is run on churn. That mismatch is not accidental. It is baked in. See Reason #25. Oversupply makes it tolerable for employers and brutal for individuals. See Reason #1 and Reason #34.

Temp-to-perm and extended “trial” employment lock it in place. Why invest in training someone who might not be converted, or who can be cut the moment demand softens? Long auditions reward quiet survival, not learning. Ask too many questions and you look risky. Make it through and the lesson is clear: you trained yourself. See Reason #45.

The breadth people praise only sharpens the edge. Mechanical roles rely on constant self-teaching across disciplines, but the job title pretends this is normal rather than extractive. You become productive by absorbing institutional debt no one bothered to document, and then you are congratulated for being “versatile.” See Reason #8.

There are exceptions. Regulated aerospace groups. Certain energy niches. A few long-tenure firms with cultural memory. Even there, training usually stops once you’re “useful.” It is front-loaded, not sustained. The moment you can carry load, the expectation shifts to silent competence.

For most of the field, the rule is simple: if you need training, you’re already behind.

A naysayer will call this paying your dues. In medicine, dues come with a residency and a curriculum. In software, dues come with mentored onboarding and a ramp-up plan. In mechanical engineering, dues come with a parts list and a deadline. The 30,000 graduates who enter each year ensure that anyone who demands formal training can be replaced by someone who will not.

The system survives because enough people accept this as normal.

Reason #51: Compliance Eats the Interesting Work

You will learn this the first time a shipment pauses for a missing label. The part works. The test passed. The mechanism does what it is supposed to do. None of that matters until the paperwork proves it. The mechanism was the easy part. The proof is the job. (See Reason #33)

Mechanical engineering is where hardware meets the world, which means it is where rules attach themselves. UL wants the label redrawn. CE wants a technical file that looks like a small encyclopedia. RoHS and REACH want material declarations that do not exist until you beg a supplier for them. Traceability wants serial ranges, travelers, and records that survive the next audit cycle. Document control wants the same drawing you just released, but re-released, because the customer portal rejects embedded fonts and your PDF is now “noncompliant” for reasons that have nothing to do with the part.

This is how the interesting work gets eaten. You start the week thinking about stiffness, creep, vibration, heat. You end it hunting down a certificate, rewriting a user manual paragraph, and building a “prove it” pack for someone who will skim for a signature line. A bracket change becomes a labeling change. A gasket change becomes a material disclosure change. A supplier swap becomes a traceability crisis. The work is still real, but it is no longer design-forward. It is defensive, administrative, and endlessly repeatable by whoever has access to the portal and enough patience to keep clicking. It also pairs perfectly with the meeting culture that turns your calendar into the product schedule (See Reason #42)

And it quietly reroutes ambition. The deeper you go into compliance artifacts, the less your “mechanical” identity matters. Regulatory specialists, quality, and program management become the people who “own” the outcome, because ownership is defined by what gets filed and what gets approved. Your fancy electives do not help you when the bottleneck is a declaration, not a design (See Reason #41) What part of this resembles the work you pictured when you chose ME?

A naysayer will say compliance is part of every discipline. It is. But in software, compliance is a checklist before deployment. In mechanical engineering, compliance is the deployment.

You will still call it engineering, because “paperwork kept the shipment legal” does not sound like a career.

Reason #47: You Mistake Motion for Progress

You stay slammed all week and nothing actually moves. The calendar fills itself: morning stand-ups, DFMEA reviews, risk burndown updates, cross-functional huddles about issues you remember from last quarter. Each meeting generates action items, each action item spawns a thread, every thread ends in a fresh invite. By Friday you have closed ECOs, updated Jira tickets, cleaned up BOMs so the ERP report looks tidy, and replied-all on three chains about the same tolerance stack. You have been very, very busy. The product has not moved an inch.

This is not a time management problem. It is a feedback loop problem, and it is specific to mechanical engineering. In software, elite development teams deploy to production multiple times per day and know within hours whether a change worked or broke something (DORA, 2024). A software engineer who spent a week on busywork would see it reflected in deployment metrics by Friday. In mechanical engineering, the feedback loop between your engineering change and physical reality is measured in weeks or months. A single hardware prototype cycle averages 19 weeks (Havukainen et al., 2024). A full validation sequence from DV through PV can take six months or more. You will not know whether your week of work mattered until the test fixture is loaded and the data comes back, and by then you are three sprints deep into the next problem (see Reason #36).

That gap is where the confusion lives. Management cannot distinguish productive engineering from unproductive engineering in real time because the physical product moves on its own schedule, not yours. So management measures what it can see: ECOs closed, gate reviews passed, tracker cells filled, status boards updated. None of these measure whether the product improved. They measure whether you performed the visible rituals of progress. A green tracker does not mean the design is sound. It means someone filled in the cells. You already know the report became the product (see Reason #33). This is why.

Other engineering disciplines do not have the same gap. Chemical engineers get continuous process data: flow rates, yields, purity readings arrive in real time and tie directly to the work done that shift (see Reason #38). Software engineers get deployment metrics, error rates, and user telemetry the same day. Civil engineers pour concrete and it either passes inspection or it does not. The feedback is slow by software standards but still directly tied to physical output. Mechanical engineering sits in the worst position: discrete products, long validation cycles, and no real-time outcome metric that connects your Tuesday afternoon to the product's Wednesday performance. The process metrics fill the void, and once they do, they become the job (see Reason #26).

The naysayer will tell you to work smarter. Push back on meetings, protect your calendar, focus on high-value tasks. That advice assumes the problem is personal discipline. It is not. The problem is structural. When the feedback loop between action and consequence is 19 weeks long, no one in the building can prove that this week's churn was unnecessary until the hardware arrives. The manager who filled every gate review on time looks competent. The engineer who skipped three meetings to run a hand calculation that prevented a tooling rework has no metric to point to. The system rewards visible motion because visible motion is the only signal it can read. You can be as disciplined as you want. The structure will still measure you by how many loops you kept spinning, not by what the product did when it finally showed up (see Reason #1).

Meanwhile the physical world remains stubborn. The plant still trips the same interlocks. The warranty data barely moves. That chronic vibration problem keeps reappearing under a new code. Your title does not change. Your pay creeps along. The big design problems quietly roll forward to the next quarter, the next engineer, the next reorg. What advances, reliably and on schedule, is the churn itself.

You will be very busy. Your career will stay exactly where it is.

References

DORA Team. (2024). Accelerate State of DevOps Report 2024. Google Cloud. https://dora.dev/research/2024/dora-report/

Havukainen, M., Rhyner, R., Kamal, M. A., & Bakhtiari, B. (2024). Strategic styles of hardware product development could accelerate commercialization in cleantech startups. PLOS Sustainability and Transformation, 3(7), e0000101. https://doi.org/10.1371/journal.pstr.0000101

Reason #43: Gender Ratio'd 8:1 at Work, 5:1 at School

Start with the math. In mechanical engineering, women earn about 17.9% of bachelor’s degrees. That is roughly 5:1 men to women (American Society for Engineering Education [ASEE], 2024). 

It does not balance after graduation. In the U.S. workforce, women are 11.4% of employed mechanical engineers, which is about 7.8:1. Call it 8:1 if you like (U.S. Bureau of Labor Statistics [BLS], 2025). Compared with the usual suspects, ME is near the bottom. Among branches with published workforce shares, only aerospace is lower. Electrical sits a bit higher. Civil and chemical are higher still. Industrial is higher again (BLS, 2025).

Those ratios matter when you are young and building your life. College and the first few years of entry-level work are where most people form friend groups, meet partners, and find early mentors. In ME the pool is skewed before you show up, and it narrows as you move through labs, clubs, and late projects. The social world that rides along with your major has fewer mixed-gender spaces and fewer same-gender peers for women in particular. The long hours do not help.

If you are a man, you will spend four to six years (see Reason #2) in rooms that feel like a sausage fest, then step into offices that feel the same. If you are a woman, you will look for same-gender classmates to team with and for mentors who look like you, and find fewer. That is not a single bad course or a single bad shop. It is the standard mix for this field in this country, repeated each fall when the next cohort arrives with the same ratios (ASEE, 2024; BLS, 2025).

You can build a career here. Many do. The shape of your days will still reflect the headcount. Fewer options for who to study with, fewer options for who to ask hard questions after a design review, fewer informal networks where people pull each other along. That is not neutral background. It is the water you swim in.

A naysayer will say this is a STEM-wide problem. It is not. Computer science awards 22 percent of its bachelor's degrees to women. Chemical engineering: 37 percent. Industrial: 40 percent. Mechanical engineering: 17.9 percent (ASEE, 2024). The problem is not STEM. It is this branch of it.

Eight to one is not a community. It is a headcount. 

References

American Society for Engineering Education. (2024, October 27). Engineering & Engineering Technology by the Numbers, 2023. https://ira.asee.org/wp-content/uploads/2024/10/Engineering-Engineering-Technology-By-the-Numbers-2023-27-October-2024.pdf

U.S. Bureau of Labor Statistics. (2025, January 29). Table 11. Employed persons by detailed occupation, sex, race, and Hispanic or Latino ethnicity (2024 annual averages). https://www.bls.gov/cps/cpsaat11.htm

Reason #42: Meetings, Not Machines

You picture torque curves and heat sinks. You get calendars and portals. Most days in mechanical engineering, the work that moves is the work you schedule, summarize, route, and sign. Slides go out, trackers go green, and the machine is a rumor you visit between standups, (see Reason #9). 

The cadence is administrative by design. You inherit DV/PV plans across three owners, reshuffle a thermal soak because the chamber is booked, then paste a tidy roll-up for a manager who will skim the bullets and ask for a risk line. A supplier flips a flange spec and your day becomes ECO forms, updated GD&T, and a DFMEA revision that must stop blinking before Purchasing can issue parts. Nothing here is fake. It is simply not engineering as you imagined it. The technician fixes the wobble; you narrate why the deviation can ship and collect signatures that prove diligence (see Reason #16).

Tools tell the story better than titles. Teamcenter or Windchill for PLM. SAP dates fighting the MRP. A PPAP packet that wants FAIRs, control plans, and a capability slide nobody reads twice. CAPA closures that live in SharePoint. Jira tickets that are really email with numbers. The plant asks for a deviation before lunch; Compliance asks for a UL note before close. You spend your afternoon re-exporting a PDF because the vendor portal rejects embedded fonts. The “design” lives in the margins: resize a gasket land, bump a fillet, add a keeper washer so the drop test clears.

This is what “cost center” work feels like from the chair (see Reason# 23). You are measured on variance and on-time artifacts, not on authored mechanisms. The tasks that count are custodial: keep the fixture repeating, keep the bill of materials aligned with the ERP, keep the document control clean so Audit has something to file. When the shaker queue slips, you defend schedule on three calls, not with a wrench but with calendar triage. What part of this resembles “engineering” as you pictured it.

A software engineer's standup ends with a deployment. A chemical engineer's shift ends with a yield report. Your standup ends with a tracker update and another invite.

You can tell yourself the meeting is where decisions happen. Often the meeting is where decisions are recorded. The real calls were made upstream, yesterday, by people you do not see (see Reason #32). You will keep the paper moving. The paper will keep the product moving. Your title will keep you in the room.

Reason #40: If It’s Admin, It’s Automatable

In 1994, the Automotive Industry Action Group published QS-9000 and replaced three proprietary quality systems with one. Ford's Q-101, Chrysler's supplier manual, GM's Targets for Excellence, all collapsed into a single standard with five core tools: APQP, PPAP, FMEA, MSA, and SPC. PPAP alone defined eighteen standardized elements every supplier had to produce (AIAG, 1994). Before that year, your DFMEA belonged to a relationship. After it, your DFMEA belonged to a template. See Reason #51. That was the year your work became portable.

The market noticed. Global engineering research and development spending reached $1.53 trillion in 2024, with approximately 70 percent of engineering services delivery now performed in offshore locations (NASSCOM & Everest Group, 2025). India's engineering R&D sector grew from $20 billion in 2015 to roughly $134 billion in 2025 (Zinnov, 2015; NASSCOM, 2025). Bain & Company, surveying over 500 senior engineering executives, found that mechanical engineering was the original discipline outsourced and is now classified as a "legacy" operation that providers have "significantly optimized" (Bain, 2023). The consulting firms that study your field call it legacy. See Reason #21 and Reason #23. Meanwhile, U.S. engineering services employment grew at 2.8 percent annually over the same period (BLS, 2024). The work did not expand at home. It moved.

What moved was everything the templates made transferable. CAD drafting and legacy drawing conversion. BOM creation and maintenance. DFMEA and PFMEA documentation. Test report writing. Tolerance analysis with predefined stack-ups. Supplier quality packages. FEA runs with boundary conditions someone else defined. An entire industry of ISO-certified offshore providers exists to perform these tasks at 50 to 65 percent cost savings (NASSCOM & Everest Group, 2025). What stayed was whatever required your body in the room: the shaker test you had to witness, the supplier audit you had to walk, the fixture you had to fit on a floor only you had visited. See Reason #52. The division was never about skill. It was about whether the work could be written down. Economist Alan Blinder found "little or no correlation between an occupation's offshorability and the skill level of its workers" (Blinder, 2009). The correlation was with codification. If it fit a template, it fit a time zone.

Other engineering branches did not get hit the same way because their work resisted the same codification. Civil engineers stamp bridges and buildings under PE requirements that anchor the work to a jurisdiction. See Reason #58. You cannot offshore a structural seal. Electrical and computer engineers work in innovation cycles fast enough that the framework changes before anyone can templatize it. Chemical engineers run processes tied to specific plants, proprietary formulations, and safety constraints that do not survive a handoff to a team that has never smelled the reactor. Software developers get offshored too, but they get offshored as developers, building new products at scale, not as documentation processors filling in legacy templates. Mechanical engineering was the original discipline outsourced because it was the first one whose deliverables were fully standardized into auditable, portable artifacts. Bain's 2023 survey of engineering executives is explicit: ME is now classified as a "legacy" operation, while digital engineering, the territory of EE and CS, commands a dominant 62 percent of the global engineering services outsourcing market (Bain, 2023; FMI, 2025). The other disciplines got offshored to grow. You got offshored to optimize.

The academic literature identified the mechanism decades ago. Codification of tacit knowledge into standardized artifacts is the prerequisite for both outsourcing and automation (Balconi, 2002). Once a DFMEA lives in a structured template rather than in someone's judgment, it no longer needs to live in the same building as the product. The National Academy of Engineering said the quiet part plainly in 2008: "the same standardized tasks have increasingly been replaced by software tools that can perform them automatically" (NAE, 2008). Standardization did not just make the work movable. It made the work scriptable. See Reason #33 and Reason #65.

You survived your workload by standardizing it. You built the templates, wrote the procedures, and turned judgment calls into dropdown menus so the volume would not crush you. Every shortcut you created to stay afloat made the next person cheaper and the person after that optional. The sequence was not accidental. Standardization made it portable. Offshoring proved it was cheap. See Reason #68 for what comes next.

You paved the road. Someone else will drive on it.

References:

Automotive Industry Action Group. (1994). QS-9000 Quality System Requirements. AIAG.

Balconi, M. (2002). Tacitness, codification of technological knowledge and the organisation of industry. Research Policy, 31(3), 357-379. https://doi.org/10.1016/S0048-7333(01)00113-5

Bain & Company. (2023). The digital shift fuels outsourcing in engineering and R&D. https://www.bain.com/insights/the-digital-shift-fuels-outsourcing-engineering-r-and-d-report-2023/

Blinder, A. S. (2009). How many U.S. jobs might be offshorable? World Economics, 10(2), 41-78. https://www.princeton.edu/blinder/papers/07ceps142.pdf

Bureau of Labor Statistics. (2024). Employment for engineering services (NAICS 541330). Retrieved from FRED, Federal Reserve Bank of St. Louis. https://fred.stlouisfed.org/series/IPUMN541330W200000000

Future Market Insights. (2025). Engineering services outsourcing market report. https://www.futuremarketinsights.com/reports/engineering-services-outsourcing-market

NASSCOM & Everest Group. (2025). The global ER&D shift: Evolution of engineering services and India's competitive edge. https://nasscom.in/knowledge-center/publications/global-erd-shift-evolution-engineering-services-and-indias

National Academy of Engineering. (2008). The offshoring of engineering: Facts, unknowns, and potential implications. The National Academies Press. https://doi.org/10.17226/12067

Zinnov. (2015). Global R&D services outsourcing market report. Via PR Newswire. https://www.prnewswire.com/in/news-releases/global-rd-services-outsourcing-market-grew-by-87-in-2015-530816321.html

Reason #38: The Other Engineers (and Techs) are Happier

Feeling the pinch from underpayment, See Reason #27, you look up your job title on PayScale and see 3.69 out of 5 for job satisfaction. Then you check the neighbors. Electrical engineers sit at 3.90. Civil at 3.93. Chemical at 3.92. Software at 3.96. Aerospace at 3.98. That non-ME cluster averages about 3.94. Mechanical engineering trails it by roughly 6 percent. Same method, same scale, same five-point survey across every page. The report is the product, the meeting is the milestone, and the drawing is the deliverable, See Reason #33 (PayScale, n.d.-a through n.d.-f).

A second survey with a larger sample confirms the pattern and adds a dimension PayScale does not measure. CareerExplorer's ongoing career satisfaction survey, drawing from over 1,800 mechanical engineers, rates the discipline at 3.0 out of 5 stars. That places mechanical engineering in the bottom 33 percent of all careers. Not just behind other engineers. Behind most professions. Aerospace engineering scores 3.4 and sits in the top 34 percent. Software scores 3.2. Electrical scores 3.1. Same job title family, different ends of the satisfaction spectrum. The most revealing subdimension is meaningfulness. Mechanical engineers rate the meaningfulness of their work at 2.7 out of 5. Nearly half, 47 percent, rated it a 1 or 2. If you spend your days shepherding ECOs, massaging BOMs, and closing CAPA logs so production can move (See Reason #26), that number will not surprise you (CareerExplorer, n.d.-a through n.d.-d).

Even the technologist variant edges you out. PayScale shows mechanical engineering technologists at 4.00 on the same scale. The sample is small, so the asterisk applies, but it matches what you feel on the floor. The technologist stands the rig up (See Reason #16). You write the report that explains why it did not move faster. Satisfaction tends to follow ownership of the thing that moves the needle, not the slide that proves you tried, See Reason #32 (PayScale, n.d.-g).

The roots go back to school and the pipeline you were sold. You were told the math would open the doors, then you watched doors open for people who could make the fixtures repeat by Friday (See Reason #31). That mismatch between syllabus and shop feeds the quiet drag you see in the ratings. It also explains why the longer program and the detour semesters feel wasteful when you land in a role that is mostly validation and status updates (See Reason #2).

You will not hate it. You will just like it less.

References:

PayScale. (n.d.-a). Mechanical Engineer salary. https://www.payscale.com/research/US/Job=Mechanical_Engineer/Salary

PayScale. (n.d.-b). Electrical Engineer salary. https://www.payscale.com/research/US/Job=Electrical_Engineer/Salary

PayScale. (n.d.-c). Civil Engineer salary. https://www.payscale.com/research/US/Job=Civil_Engineer/Salary

PayScale. (n.d.-d). Chemical Engineer salary. https://www.payscale.com/research/US/Job=Chemical_Engineer/Salary

PayScale. (n.d.-e). Software Engineer salary. https://www.payscale.com/research/US/Job=Software_Engineer/Salary

PayScale. (n.d.-f). Aerospace Engineer salary. https://www.payscale.com/research/US/Job=Aerospace_Engineer/Salary

PayScale. (n.d.-g). Mechanical Engineering Technologist salary. https://www.payscale.com/research/US/Job=Mechanical_Engineering_Technologist/Salary

CareerExplorer. (n.d.-a). Are mechanical engineers happy? https://www.careerexplorer.com/careers/mechanical-engineer/satisfaction/

CareerExplorer. (n.d.-b). Are aerospace engineers happy? https://www.careerexplorer.com/careers/aerospace-engineer/satisfaction/

CareerExplorer. (n.d.-c). Are software engineers happy? https://www.careerexplorer.com/careers/software-engineer/satisfaction/

CareerExplorer. (n.d.-d). Are electrical engineers happy? https://www.careerexplorer.com/careers/electrical-engineer/satisfaction/

Reason #37: The Vendor Writes Your Design

Your “new product” kickoff starts with a parts list you didn’t write. The motor comes as a package with the gearbox, the controller, and the exact bolt pattern the vendor’s catalog has had for twenty years. Your CAD opens on their STEP, not yours. The meeting ends with assignments to confirm hole clearances and draw a bracket for someone else’s box, see Reason #33. 

This is how mechanical work narrows. Procurement wants NEMA or IEC frames because the shop stocks them. Compliance wants UL-listed assemblies because the test plan is shorter. Quality wants suppliers with PPAP history. All of that is sensible, and all of it moves the lever arm away from you, see Reason #26. The compressor is a vendor skid. The battery is a module with a sealed BMS and a CAN spec you cannot see. The hydraulic power unit is a catalog manifold with port patterns you will not change. You integrate, you shim, you reroute hoses, and you call the outline “architecture.”

Even the analysis comes pre-baked. The vendor FEA drives the wall thickness. Their performance map decides your operating points. Their harness length sets your enclosure and your thermal path. Your drawing says “per supplier print” in more places than it says anything else. When a tolerance stack fails, you revise your plate, not their casting, because their tooling is amortized and your plate is cheap, see Reason #21.

Academia sells first-principles freedom. Industry sells parts that already exist. In the gap (see Reason #32), your creativity turns into constraint management: REACH certificates in the portal, CE clauses on the nameplate, ERP/BOM numbers that make the ECO route clean. You can call this “systems thinking.” It often feels like shopping with paperwork. See Reason #2 if you want to remember how many semesters you paid to be here: 

Glut writes the spec. When ten COTS products queue for one project, managers pick what they can defend: catalog modules with warranties and part numbers already living in ERP. Risk shifts to the vendor, and most choices go with it. You weren’t out-engineered. You were out-supplied by lead times and a price list, see Reason #23.

A naysayer will tell you integration is real engineering. It is. But the engineer who integrates someone else's design has less leverage, less ownership, and less claim to the outcome than the engineer who created it.

You will learn a lot about vendor portals. You will learn less about making something from zero, see Reason #14.

Reason #36: Testing Is The Job

Your first “design” assignment is a spreadsheet. You inherit a DV/PV matrix with a hundred rows, a vibration rig queue that runs longer than your project, and a release date that only moves one way. You thought the model came first. The fixtures come first. The plan comes first. The report gets written before anything breaks (see Reason #33). 

This is not an accident. Mechanical work is judged by what survives. So you learn to schedule shaker time, thermal soak cycles, and drop tests before you learn to explore. You machine coupons for fatigue because certification asks for numbers older than your plant. You write acceptance criteria that trace to UL and CE clauses. You buy more thermocouples. You design fixtures that will never be sold and debug chambers that will never leave the lab. The fun part is a sprint. Verification is the marathon.

The language shifts under you. “Design review” means the test plan. “Prototype” means a bundle of fixtures and a work instruction. “Root cause” means fill the DFMEA column that says detection. You manage polymer creep in a clamp, not a new mechanism. You chase a tolerance stack because the metrology says the fixture moved, not the part. None of this reads like the brochure. All of it reads like your calendar.

Oversupply makes the pattern stick. When there are ten résumés for every seat (see Reason #24), the safest task wins the headcount. The safest task is proving the last thing works one more time. You can call that quality. You can also call it the cheapest way to keep a line running while the new ideas live somewhere else (see Reason #21 and Reason #7).

Management loves testing because testing is visible. Schedules track green boxes that say complete. Finance loves it because the spend is traceable to requirements (see Reason #23). You will love it on the days when the fixtures repeat and the plots behave. What part of that sounds like design?

Software tests run in seconds and report results the same day. Chemical process validation produces live yield data. Mechanical validation takes weeks, consumes fixtures, and generates reports that outlive the engineer who wrote them.

If you picture yourself drawing the future, prepare to spend most days measuring the present and filing it.