How Technology Really Gets Created

When I was a little girl, I was briefly obsessed with space travel and astronauts and rockets. It didn't take long for me to come to grips with the fact that it was incredibly unlikely I would ever be an astronaut, so I decided to dream about being close to space travel in some other way instead. Some part of me understood that even though the astronauts were the famous ones, nothing they did would be possible if nobody put fuel into their rockets.

So I imagined being the person in charge of putting fuel into the rockets. That was my first dream job.

Of course, the adults around me reacted to this dream with derision, mocking and shaming me for my "small" (albeit imminently attainable) dream. I gave up on that idea fairly quickly, and even though I hurt, I was quietly assuming that someday, I too would be Grown Up enough to understand why they thought that job was less important than an astronaut's.

Many years later, I had a career making computer software. And I learned that the Grown Ups around me still had absolutely no idea what jobs are actually important.

In white socieities especially, it is common to spread the mythology of how "great technical advancements" happen. The story is practically formulaic: an underestimated, unexpected figure toils hard, usually alone or as the leader of a very small group. After a long span of time and a lot of effort, they have a Breakthrough Moment, and then there is Success.

We're told these tales all the time. We fixate on these supposedly "central" figures - the innovators, the inventors, the dreamers, the big thinkers. They are always the heroes. We know plenty of their names.

I'd be willing to bet a nice meal that anyone who reads this can name at least two famous "inventors" whose stories go like this. Probably quite a few more than that, even.

But how often can we name the inventor's janitor?

Through biographies and historical documentary projects, we often know incredible amounts of detail about these iconic figures and their lives. But how often do we know the life story of the person who cleaned the Big Thinker's workspace? The ones who organized their notes and their social calendars? We might know childhood anecdotes about a famous technology creator, but do we know anything about the people who fed them their meals while they did their famous work?

Our culture places a certain kind of emphasis on very specific roles within the process of creating new things - and not just in technology. We know artists, but not the people who made their raw materials. We know business executives, but not their assistants and secretaries. We know musicians and filmmakers and writers, but rarely do we really understand their support networks, if we even acknowledge them at all.

This is a facet of individualism. Despite its ubiquity, it actually has a tremendous number of bad effects. Not only does it serve to distort our understanding of how things actually work, it reinforces the notion that certain people's contributions matter more than others. In turn, this drives the ideology that, in order for us to matter more as people, we need to do the (select handful) of jobs that are thought of as "important." This entire process is crucial to convincing large numbers of people to continue to participate in the exploitation and injustice of capitalism; if the threats of going broke and being left alone and homeless are the "stick," then the notion of having a "meaningful career" is the "carrot." Both exist to coerce us into producing, and generally for someone else's benefit moreso than our own.

This story that we're told is incredibly far from the truth; but because it's an important lie, explaining the reality is generally discouraged, if not outright forbidden. Which is, of course, why I want to tell the real story. I want to describe how technology really gets created.

The Forgotten Roles

Something I observed frequently during my own career was that there was always an intense discrepancy between the job titles that were talked about as being important, versus the work that actually made businesses succeed or fail. Some roles were glamorous. If we'd made movie trailers and posters about the projects, the names of people doing those jobs would be in the biggest letters. Other roles almost never got acknowleged at all. The people doing that work were rarely mentioned, invariably underpaid, treated as disposable and nigh-on irrelevant.

And yet, as far as I could tell, they tended to also be the most reliable predictors of which projects would succeed, which would struggle, and which would fail.

This bothered me, because I had one of the glamorous jobs. I was a programmer. Even people who don't particularly have any reason to know how software is created have almost certainly heard of programmers. The culture of software development expected me to be happy - I was paid more than team members in other departments, I was celebrated more frequently, and I was protected when it came time to talk about who needed to be laid off or downsized. I was one of the astronauts. But part of me had never forgotten that nothing I did mattered - none of it was even possible - without the people who put the fuel into the rockets.

In the software world, there are roles that are sometimes called "non-technical." These are, without exception, the most important jobs in any software creation project. They are also, invariably, the ones that people treat as lesser, as undesirable, as "too small" to be worthy of dreaming about. Many times, they are talked about as "stepping stones" or "entry points" - places you can start, if you really need to, so someday you can have a Real Grown Up Job and become a programmer.

A great example of this pattern is the job of "software tester." Typically, these people are hired into departments named things like Quality Assurance. The purpose of QA departments is to analyze and poke at software that's being created, and find the flaws in it - the "bugs." Good testing is an incredibly difficult skill, and some of the smartest and most creative people I've ever worked with were testers. Without good testers, projects collapse spectacularly as soon as people start trying to actually use them. Testing is what makes the difference between an interesting idea for software and a really good project. Despite being thoroughly pivotal to project success, QA is famously regarded, in most of the software industry, as "grunt work." Unimportant, secondary, not worth paying for, and certainly not "skilled."

QA staff are not protected when the budgets get tight. They're not courted with six-figure contracts and stock options. QA jobs are famously rough, over-worked, and have incredibly high turnover. Because QA continues to be advertised as an "entry point" for "better" careers, there's always an endless supply of cheap, willing recruits to throw into the machine, no matter how many it grinds up and spits out.

But if I want to know how successful a software project will be before it launches, all I need to do is have an honest, vulnerable talk with the QA team for a few minutes, and I can give a shockingly reliable prediction of the project's future. The more QA is underpaid, underappreciated, deprived of resources, and considered a necessary annoyance - that is, the more a QA department is treated like they usually would be in the industry - the less likely the project is to be healthy and long-lived.

I will never forget a particularly tense meeting I had, late in my career. At the time, I was the director of technology for the company I was working for. The business had just gone through a financially brutal year and some very disruptive layoffs, followed by several dramatic changes in senior management. The newly-minted head of the company had a meeting with me (and other department heads) to plan out where to spend money on hiring new staff. The budget was thin, and it wasn't going to be possible to hire everyone we needed, so careful prioritization was necessary. It was a time of making a lot of truly hard decisions.

Without any hesitation whatsoever, I looked the executive in the eye and told him if there was a choice to be made between hiring one more programmer (into my department) and one more QA tester (not my department), I'd demand he give my budget to the QA team, every single time. And I'll never forget the look of confusion and irritation on his face.

QA testers are not the astronauts. I broke every rule of corporate politics in insisting that my budget be taken away from the astronauts in that meeting. But I knew the truth the executive didn't want to think about: there's no point in hiring an astronaut to sit in an empty, unfuelled rocket.

I could write an entire book about all the work that is regarded as "less than" programming, in the software world: technical writing, project coordination, task load analysis, defect (or "bug") pattern analysis, testing, accessibility planning, user research, aesthetic design, keeping people happy and content and fed and rested... all work that is, invariably, paid less and celebrated less than "programming." And yet, from my own perspective and experience as a programmer, all of these are more important to the creation of software than programming.

Yes, programming is necessary. But it's the least important requirement for making new things. And the projects that really shine, for the long term, tend to be the ones that understand that programming isn't the most important part of the work.

In fact, I would argue that the most important roles in the creation of any technology are both intensely technical (in that they require intricate, specialized, and difficult skill-sets) and also have very little relationship to technology per se.

What Actually Matters

There is plenty to pick apart and explore in terms of how typical tech projects get things wrong - whether in startups, or massive corporations, or open source, or academia. For the sake of focus, however, I want to just start fresh. Let's consider a blank slate - push aside any and all assumptions we might have about how things get made, and what the important bits of that process are. From there, I want to explain what I think really is important.

To do so, I'd like to tell a personal story.

After I left the software industry, I decided to start this little venture here at SpoonStack. It's an experimental project, involving a lot of new ideas and approaches to making software and creating tech in general. The whole point is to demonstrate that there are better ways to do things than are typically offered by the status quo.

As I'm writing this particular essay, I am the only active programmer at SpoonStack. But I am far from the only person who is involved in the work. What I do is important and necessary for the project to even exist - but in a very real way, I think the programming is, again, the least important requirement.

I was ejected from my last job by the joint abuse of a group of sexist, ableist, transphobic male authority figures (including, funnily enough, the guy who was mad I wanted to hire QA instead of programmers). At the time, I had almost no meaningful social support outside of the company, and after the events that led to my departure, virtually all of my former colleagues essentially ghosted me as well. There were two people who ended up helping me survive the emotional turmoil and upheaval of exiting that job, and who helped me process the fallout.

One was a disabled friend I'd met in an online video game; we've since had to part ways for unrelated reasons, but she was the original inspiration for the SpoonStack project, and even gave it its name. Nothing I'm doing now would have happened if not for her. She taught me the power of disabled people moving in solidarity with each other. And she sparked a chain of ideas that became my life's work.

The other critical person at SpoonStack is my long-distance partner, Quinn. We'd been together for about two years when everything imploded at my job. Without their presence, support, and encouragement, my final year in the industry would have played out very differently. In fact, their effect on my life is nothing short of profound; my own sense of self-worth and self-protection was very badly shattered during my childhood (and chunks of my adult life as well), and they directly contributed to a genuinely indescribable amount of healing and change for me, in those areas as well as many others. I probably wouldn't have been able to recognize or escape the hell I was put through by my bosses, in the years after I came out as trans, if not for my relationship with Quinn.

I know they've been a huge part of my motivation to do something with my experiences - to turn two decades of frustration and thankless advocacy in the software industry into something that really matters in the long run. But their importance to the SpoonStack project doesn't stop there.

Quite the contrary, Quinn is nothing short of essential to the overall work of SpoonStack. We have numerous ongoing conversations with each other - about social justice, about what it means to care about ourselves and each other, about the nature of good relationships and good communities, about how to identify and mend patterns of harmfulness and oppression in ourselves as well as the world around us. We spend countless hours, on the phone together, exploring our own lives and experiences, and thinking together about ways that these things connect to larger phenomena in the world. We think about how to understand difficult things, how to share what we are learning and doing, how to be an effective part of the effort to make things better.

Ultimately, this is exactly the ethos of SpoonStack - not because I set out to do things that way, but because our consistent, frequent, repeated interactions have shaped things that way. As N.K. Jemisin wrote, "relationships chisel the final shape of one's being." I would not have known what values and principles really matter the most to me, if not for talking so much with Quinn.

So what does this have to do with creating technology?

After I found myself unemployed, I wouldn't have had any idea what to do, what to make, or even if I wanted to keep working with technology at all, without Quinn, and without the shared values we've cultivated together.

The trick is, everything starts with those values. Those principles.

Business executives and project leaders and movement organizers often get caught up in trying to make plans about what to do. There is a truly absurd amount of effort put into "project planning" in a typical software endeavor. What very few leaders recognize is that, a lot of the time, the planning isn't actually helping them. Ironically, the worthlessness of software planning has been documented - and even been the subject of scientific studies - since the 1950s, but "development leaders" continue to refuse to learn from history. Most of the career software executives I knew had never even heard of the research, 70 years after someone had first suggested maybe the planning wasn't a great idea.

The trouble is, plans are made around assumptions and best-guesses and expectations; but we never guess perfectly. Something always happens that is not according to plan. Always.

So plans are fragile, and often brittle. This means that when the inevitable occurs, the plans have to be adjusted, or even remade entirely. This is a costly, disruptive, and frustrating experience; and most people who lead projects - not just in software or tech in general - seem to believe that it is a necessary evil. They may bicker about how often to redo the plans, but they all pretty much think planning is somehow a requirement.

I disagree. Instead, I start from principles.

If we know what is important to us, we have ways to make decisions. If we know how to make decisions, in the moment, we can adapt when things come up. And when we're truly, deeply familiar with what is happening in the present, we can smoothly, gracefully adapt along the way, no matter what happens. It's not that we don't make any plans at all anymore - but we learn to be less attached to specific details of our plans. We learn to be honest with ourselves about what we can actually predict and control (spoilers: basically nothing). We learn to become sensitive to the ever-shifting reality of our collective situation and our collaborative effort. We inevitably begin to care about the relationships and interaction dynamics of the people we're working alongside, because those are the things we can really truly influence the most, and those are the things that have the most impact on our overall results.

In short, we learn to live and to grow. Our ideas about teams and projects stop resembling factories and assembly lines, and start resembling rainforests: full of flowers and shrubs and trees and insects and birds and small animals - wild, untameable, but almost infinitely vibrant and vital.

This approach is, admittedly, very much at odds with capitalistic pressure - which demands predictable timelines, increases in revenues, increases in customer engagement and retention, always more, always sooner. To operate healthily - and sustainably - is inherently at odds with greed. I'm no longer particularly surprised that I was ultimately kicked out of a company that I'd been instrumental in helping to survive, let alone succeed, for more than a decade; in the end, my understanding of how to be good at making software was never going to line up with the insatiable lust for bottomless profit and power.

But it turns out that even though capitalism rejects this approach, the pattern is still important. It's pretty rare for anyone in software to spend a lot of their time talking about principles, or how to create organic strategy, or how to care about each other; but that doesn't mean those things don't matter. They're just erased. And to the extent that organizations don't explicitly think about these things, they actually undermine their own potential. All the apparatus of control and predictability only wind up backfiring, because nobody's thinking about what actually matters.

And this is not just a problem in for-profit companies. Not long before I sat down to start drafting this, there was a huge upset in the "open source" software world, where a malicious person had slowly wormed their way into a few key projects and successfully hid scecurity back-doors in various pieces of popular software. The misdeed was discovered, almost by accident, before any real harm could be done - but it's illuminated how profoundly the open source movement has failed to actually create a viable ecosystem. Large parts of the plot relied on exploiting undervalued, under-supported people, and abusing trust. In short, open source doesn't actually understand what matters, either, because - true to the overall cultural mythos, and the fairy tale of the "creative genius in a garage inventing new things" - open source subculture reveres programmers above all else. And the astronauts are panicking, having very nearly found themselves strapped into a rocket full of demolition explosives instead of fuel.

The comfortable and happy ignore the weak and vulnerable at their own peril.

Without caring about people, we don't know what actually matters. Without knowing what's important, we have no guiding principles. Without principles, our strategies may indeed succeed for a time, but ultimately, they'll become stale and brittle - leaving us exposed to direct opposition, or irrelevant and ripe for being swept aside by the "next big thing." Without flexible, adaptive strategies, the tactics and plans we choose will be aimless - perhaps we have a good skirmish, a positive fiscal quarter or two, but ultimately, any sense of predictability and control we might have is mere illusion. Without selecting good tactics, and making small plans, we have no idea what to do, day to day, moment to moment. We are lost.

Success, then, ultimately hinges on how much we're invested in caring - about ourselves, and at the same time and in equal measure, about each other.

Perhaps one of the biggest lessons I hope to teach, via SpoonStack, is that there's much more to making things than "technical skills." Tech companies fret all the time about how to dig up sources of "innovation." Every tech company in all of history is one good invention away from permanent irrelevance - if that idea is brought to life someplace else first.

And yet for all the research, money, cultural pressure, and myth-propagating biographies... tech still doesn't understand, and perhaps never will: the most reliable way to generate innovation is to care deeply about the people the world is busy trying to leave behind.

When we really pick it all apart, that's the true story of how technology really gets created - not the story of who gets the credit or the rewards, but how it all actually works.

I hope, in the end, that this story reveals something important, to everyone who's just assumed they'll never be a relevant part of creating new technology, to everyone who feels like they're not "technical enough" to matter, to everyone who is frustrated by feeling left out and ignored, trying to be patient with the whims of the "decision makers" who never seem to think about your perspective or experiences.

You're the ones that actually matter. And you're the ones that actually make it possible - and meaningful - to create new technology.

Don't settle for a world that only reveres its astronauts. After all, somebody has to put the fuel in the rockets.

~ Amelia