The Myth of the Pipeline Problem

The “Pipeline Problem” has been widely cited as a key reason for the dearth of women working in STEM fields, particularly as computer programmers. Fewer girls than boys are exposed to the opportunities that exist in STEM fields, girls have fewer adult role models in STEM fields, gendered toys may discourage girls from learning about problem solving and the joy of building. Women make up less than 20% of computer science college grads, etc.

My Path Through The Traditional “Pipeline”

I am a personal counterexample to all of these these statistics. In grade school I always tested in the 99th percentile in math and science, even as teachers warned our classes “boys often do better at these tests than girls”. I played with legos and erector sets along with barbies. I continued to be interested in math and science even in junior high when all my female classmates started pretending to be dumb at math to get the attention of boys who could “help” them. I went to science camps in high school even though it was profoundly uncool. I majored in computer science at Carnegie Mellon University, even though my mom suggested perhaps I major in something that would let me “fall back on teaching”, and that I should “make sure to have a boyfriend who can help you with your homework.” I thrived in my computer science classes. I liked having mostly male friends in college. Instead of being discouraged by the gender disparity in my chosen major, I thought it was kind of cool. At graduation I looked forward to opportunities to be some sort of lady-nerd ambassador, and prove to anyone who might doubt it that women can do the same engineering work as men. I found the possibility of sexism in my field to be yet another interesting challenge that I knew I could step up to.

The Reality of the “Pipeline” in the Corporate World

After college I went to work for Amazon for 4 years. Amazon’s interview process is notoriously difficult. Not only do most programmer candidates have to make it through the 8+ hour long coding-at-the-whiteboard interviews, but all incoming candidates are judged against the metric of “raising the bar” — whether they are more talented and ambitious than at least half of the existing staff. When I started as a Software Developer 1 in 2003, I expected to find coworkers who all went to better colleges, were all smarter and more technical than me. I expected to be working with adult versions of those whiz kids who published math papers at 13 and built their own robots in their parents’ basements- the typical wunderkind stories the media loves to broadcast.

What I found was a bunch of regular people. Hardworking, smart people, but from a surprising variety of both traditional and non-traditional backgrounds. More than half of them hadn’t even majored in computer science. There was the principal engineer who had majored in drama 25 years ago, the principal engineer who boasted about getting a marketing degree from a community college because it was “cheaper than a real college”, and a whole slew of talented coders who didn’t even have degrees at all, who happened upon computer programming as a hobby that turned into a real job during the late 90s DotCom Boom. These guys figured it out as they went along and became quite good at it. There were other recent grads like me who actually majored in computer science at what recruiters would call a “name brand university”, but we were a minority.

In all the subsequent jobs I’ve had as a software engineer over the past 11 years I have seen this demographic: more than half of my software engineer coworkers have been self-taught. When I consider the three most productive colleagues I’ve ever worked with, one majored in design, another linguistics, and another was a college dropout. None of them knew about computer science as kids, they weren’t identified by their grade schools and high schools as particularly talented in math or science. They just fell into computer programming as adults because they found it interesting, and discovered it happened to be something you could get paid to do. All of them managed to get programming jobs before they were even particularly adept at programming, and they learned on the job.

What is the Actual Path to Success in Software Engineering?

While I see a lot of value in the traditional, “Pipeline” path of majoring in computer science in college (I certainly got a lot out of it), I’ve come to the conclusion that if a person has a growth-oriented mindset and is willing to put in the hours to grow their skill set, they can become a great engineer. I wholeheartedly support my self-taught engineer coworkers and their nontechnical backgrounds.

But this brings me back to the “Pipeline Problem”- if such a great many talented software engineers get into engineering from nontechnical backgrounds and unrelated majors, why are 95% of them men? The “Pipeline Problem” does not explain this. In my work experience, I’ve seen men from all different backgrounds discover software engineering as a possible career option, and get jobs even before they have all the skills they need to be successful. They are able to learn on the job, and are supported while they are learning on the job. In a very short number of years, they are usually able to declare themselves “experts” in their chosen technical specialization.

In many big cities you’ll hear recruiters talk about “The War For Talent”- there are so many great software engineering jobs, and not enough talent to fill them! I think the real Pipeline Problem isn’t gender-specific: there is a real lack of experienced software engineering talent across all identity demographics. Because of our society’s identity biases, I think this leads to more white men getting hired into programming jobs based on potential despite lack of experience because they “fit the profile”, while white women and all people of color are expected to meet the higher standard of coming through the traditional “Pipeline.” I also think corporate environments aren’t aware that most of the engineers they employ are actually learning on the job.

What Corporations Can Do

As long as we have more engineering jobs than talented and experienced engineers, I think corporations should acknowledge they are often hiring for potential over experience, and explicitly support engineers learning on the job. And these opportunities should be available to everyone, not just those who “fit the profile” or happen to be in the right place at the right time.

Part of this is getting better at interviewing: learning how to assess potential, instead of hiring people who “seem reasonable” when you are short on candidates who truly meet your company’s hiring standards. Part of this is just good people management: you need to invest in your people by making sure they have mentors, support networks, opportunities to grow their skill sets on the job, and opportunities to go to conferences and training programs.

The Cost of Not Addressing the Problem

Another key reason the imbalance between jobs and talent should be formally acknowledged is that it has a dark side. Every earnest, hardworking engineer is familiar with this situation: while every project has its stars that carry the project over the finish line, every project also has its freeloaders who barely do any work. While I have worked with many great engineers, I’ve also worked with a surprising number of freeloaders- guys who “fit the profile”, who are always talking about their expertise, but somehow always end up blocked for yet another mysterious reason, day after day, month after month, dragging their projects down. They always have technical sounding reasons for their delays, reasons that are hard for nontechnical people managers and product managers to argue with or even understand. But the engineers know who these guys are. This is an open secret in most teams at large companies.

Surprisingly, the freeloaders are rarely laid off or even disciplined, because most companies have a shortage of engineers and balk at the possibility of reducing headcount. This is an expensive problem, and a persistent confounding variable in software estimation and project management. Hiring for potential when it’s necessary, and providing real support to people learning on the job will increase the number of talented employees at your company and in the job market, and make it harder and harder for freeloaders to keep coasting on your company’s dime.