feature article
Subscribe Now

Attacking Ageism in Engineering

Inertia Drives Age Bias

We hear a lot these days about ageism in tech careers. Clearly, there is ample evidence that employers stack the deck in favor of younger (and also male-er) talent. Also clearly, there is ample evidence that there are complex cultural issues affecting the demographic mix in engineering. But there are other, more subtle factors at play that have a major impact on who ends up sitting at the next lab bench. And, unless we understand (and compensate for) these factors, our long-term careers and even our technology may be at risk. 

When I started my engineering career in the early 1980s, I was drawn into electronic design automation (EDA). (But we didn’t yet call it “EDA” in those days.) In particular, I was interested in place-and-route technology for chip design (mostly gate arrays at the time). Place-and-route was a hot research topic, and numerous high-end engineering schools had specialized postgraduate programs (Masters and PhD) specializing in the advancement of algorithms in that area. Every year, a strong field of advanced-degree engineering graduates emerged from engineering schools and were aggressively recruited by the various companies competing in that arena. A PhD whose dissertation had focused on some new placement or routing technique, or who had a paper published (co-authored by his professor, of course) at the Design Automation Conference could pretty much “write his own ticket” for a job in a fast-growing design automation company.

Note that I used the pronoun “his” because at that time somewhere north of 99% of graduates in that area were male. And, I’m being generous with 99%. The truth is, working in place-and-route for the first 5-6 years of my career, I met zero women with an advanced degree in those topics during that era. Why? I don’t know. But, with essentially zero qualified female candidates emerging from engineering schools at the time, we can’t fully blame industry hiring practices for the gender discrepancy.

But, we’re here today to talk about ageism, so let’s not get too far off track. My first job was at a startup developing place-and-route technology. At the time I joined, the company had approximately sixty employees. The average age was mid-20s. We had almost nobody above the age of 30 in the entire organization. The technology was new and young, and the people who had spent their college careers focusing on the emerging technology were also young. Sure, older software and hardware engineers existed (we obviously needed both skill sets for what we were doing), but virtually none had any education in the technology and techniques we required.  

Older engineers had invested their time becoming expert on older technologies, and their value in those fields was much higher than their value to a company like ours where their hard-earned expertise would have no applicability. In broad strokes, we could hire young engineers with substantial expertise directly applicable to our problem, or we could hire older engineers with no background in our technology at all, hoping that their experience, wisdom, and semi-related experience would allow them to come up to speed quickly. And, while that dilemma would have been worth debating, it was a moot point. No older engineers ever walked through the door looking for a job. If they had, they would have found a building full of “kids” speaking a language they did not understand, and working for salaries that were below their expectations. Older candidates self-selected and never applied in the first place. 

By the way, we are using place-and-route as an arbitrary example technology here, but let’s continue. For the next couple of decades, place-and-route technology matured. At the same time, the group of engineers with expertise in place-and-route matured. Ten years after I was hired, the average age in companies like mine was ten years older. By and large, the same engineers who had begun their careers as experts in the field had continued in that field. Now, having done their graduate degrees and spent a decade immersed in industry in a single technology, their value working directly in that area was MUCH higher than in any other area of engineering. If they wanted to continue to reap the rewards of all those years of work, they stayed put.

Of course, technology didn’t stand still. Over the next couple of decades, place-and-route moved closer to what the industry would consider a “solved” problem for business purposes, meaning EDA companies could scale back their engineering efforts to more “maintenance” and “evolution” rather than pumping resources into trying to create a new breakthrough. At the same time, academia began to lose interest. New engineers weren’t chomping at the bit to choose “place-and-route” as their focus in graduate school. There were new, shiny, emerging technologies that were perceived as more attractive. The supply and quality of talent emerging from engineering schools in our area slowly dwindled. 

For the initial crop of engineers, this amounted to job security. They were the world’s experts in a highly useful technology, and there was not a younger, fresher set of challengers coming to compete with them for jobs. At the same time, however, the actual number of people required by industry slowly diminished. Tech companies moved mature technologies into “cash cow” mode, and kept smaller teams of engineers to sustain them. Bright, innovative ideas were no longer required. The long tail had begun. 

This effect, of engineers entering and aging within a single field has been pronounced in just about every discipline I’ve explored. Today, if you go to an EDA company and find a group working on place-and-route, you may discover that the engineers are about my age on average. Many of them will have worked in this area their entire careers. If I pick a technology that came along a decade later, you’d probably see that the engineers are a decade younger on average. The forces of inertia that keep engineers working on the same problems with which they began their career, are too strong for most of us to overcome. Higher pay, the reward of being recognized as an expert in something, the comfort of a peer group that is about your same age and experience, and fear of the unknown all conspire to keep us where we are. 

Today, a completely new set of skills is on the front burner. Data science, neural networks, and a host of other “hot” engineering problems are attracting many of the best and brightest at engineering schools. Those who emerge with advanced degrees and accolades will have amazing career opportunities. We will certainly see numerous startups and innovative companies with very young teams of “digital natives” making huge breakthroughs in these areas. But, if we took a core sample of the technologies on which those hot new topics are built – from the processors, servers, compilers, networking technology, EDA tools, semiconductor fabrication, and on and on, I’ll wager you’d see a group of expert engineers in each whose average age is roughly the age of the technology plus 25.  

Some engineers are content to follow this career path. They like spending their careers refining their craft and expertise, working to become the best-of-the-best in a specific domain. They understand that there is attrition along the way, and the price of that choice may be finding themselves unemployed (and almost unemployable) at some future date when only a handful of experts are required in that field. Others are not, however, and, for those engineers, it is important to be constantly challenging our boundaries, studying emerging technologies – particularly those in neighboring areas to our own, and pushing back our fear to make the leap off the well-oiled tracks. The engineers who free themselves from this path are rare. They are the ones who are constantly pushing against their fears, learning new things, building their expertise in learning itself, rather than in a particular technology or discipline.

Aside from limiting our career path, this stratification of ages and technologies has a hidden sinister side. As the experts in a particular technology retire, we reach a situation where they have not been back-filled by younger talent. The industry actually risks losing its ability to maintain, advance, or adapt older-but-essential technologies. Particularly in software, we are accumulating vast amounts of code that no currently-working engineer understands. The prospect of reverse-engineering something so subtle and complex can be daunting, and we could very well face industry-scale crises where problems emerge that nobody knows how to fix.

Technology companies have a lot to overcome to build a more robust, more diverse workforce that can both innovate and maintain our critical technology stack. The current bias-driven and inertia-dominated career path will require active measures to correct. However, the consequences of ignoring the problem are damaging to us all.

One thought on “Attacking Ageism in Engineering”

  1. Interesting, Kevin. One additional note: you focused on the career events of hiring and retiring. But there’s also the layoff thing, and it’s hard to know whether, given that a layoff is a cost reducer, those chosen are older because they earn more.

    I’ve seen behavior in the past that suggests that youngsters are prized for two reasons beyond those you point out:
    – One you alluded to: they cost much less (especially if they’re still living in Mom’s basement); the difference here isn’t that an experienced person might not feel attracted by the position, but rather that the hiring manager would be able to make a smaller offer to someone younger. (Most engineering roles aren’t posted with specified salaries; you might not know until the offer comes – and if you’re older, that offer simply might not come).
    – They don’t yet have lives. There are certain types of managers that have little time for employees with parental duties or even marriages to maintain; older employees tend to have these issues – plus a general feeling that, “Wait, I’m not supposed to be working 80 hours a week my entire life! That’s BS!” 🙂 As long as there is a pool of workers that have no other needs than to work, engineers trying to be full humans will be at a disadvantage with such managers.

Leave a Reply

featured blogs
Aug 11, 2020
While Cadence System in Package (SiP) is '€“ and continues to be '€“ one of the most complete solutions for package design, the Virtuoso RF Solution gives access to a constantly increasing set of package... [[ Click on the title to access the full blog on the Cadence Com...
Aug 11, 2020
Making a person appear to say or do something they did not actually say or do has the potential to take the war of disinformation to a whole new level....
Aug 7, 2020
HPC. FinTech. Machine Learning. Network Acceleration. These and many other emerging applications are stressing data center networks. Data center architectures evolve to ensure optimal resource utilization and allocation. PECFF (PCIe® Enclosure Compatible Form Factor) was dev...
Aug 7, 2020
[From the last episode: We looked at activation and what they'€™re for.] We'€™ve talked about the structure of machine-learning (ML) models and much of the hardware and math needed to do ML work. But there are some practical considerations that mean we may not directly us...

Featured Video

Product Update: New DesignWare USB4 IP Solution

Sponsored by Synopsys

Are you ready for USB4? Join Gervais Fong and Eric Huang to learn more about this new 40Gbps standard and Synopsys DesignWare IP that helps bring your USB4-enabled SoC to market faster.

Click here for more information about DesignWare USB4 IP

Featured Paper

Computational Software: 4 Ways It is Transforming System Design & Hardware Design

Sponsored by BestTech Views

Cadence President Anirudh Devgan shares his detailed insights on Computational Software. Anirudh provides a clear definition of computational software, and four specific ways computational software is transforming system design & hardware design -- including highly distributed compute, reduced memory footprints, co-optimization, and machine learning applications.

Click here for the white paper.

Featured Chalk Talk

Microchip SAM11L KPH

Sponsored by Mouser Electronics and Microchip

Adding connectivity to your embedded design opens up a whole new realm of security challenges. Inviting your device to the IoT requires careful attention to building a secure foundation. In this episode of Chalk Talk, Amelia Dalton chats with Anand Rangarajan from Microchip about the SAML11-KPH MCU and how it can help you develop your application without worrying about security.

Click here for more information about Microchip Technology SAM L10/L11 ARM® Cortex®-M23 MCUs