Should software engineers unionize? Two years ago, I would have said “no”. In fact, I did say “no” two years ago. At the time, I was unduly influenced by the negative reputation of unions in this country, and drawing a rather artificial distinction between “unions” (blue-collar) and professional “guilds” (white-collar, often prestigious). I saw the need to draw together and collectively seek our common interest, but I gave it the language of a “profession”.
Two years ago, I argued that we needed structure of a constitutional nature, and I still agree with that. Software, right now, is an every-man-for-himself, “Wild West” industry. There are no unions, talent agents for programmers are rare to nonexistent, talented engineers are fired quickly and without apologies (or severance), and the engineer is wholly responsible for his own career advancement. (Some companies are so backward that they deduct conference attendance from vacation days!) A small number of companies (e.g. Valve, with its open allocation system that allows employees, within reason, to define their own work and pick projects) offer constitutional guarantees regarding internal mobility and social justice, but that is far from the norm. In most companies, the fundamental idea is that employee lives entirely at the whim of a manager, “and you should be thanking [him] every morning, along with Jesus, for giving you another day.” Constitutional protections of employees would be anathema to most organizations, whose internal models of social justice are akin to Elizabethan England’s “great chain of being” concept, in which the monarchy ruled by divine right and was unaccountable to anyone.
The Wild West employment climate was tolerable to most Silicon Valley software engineers when they shared in the upside (i.e. stood a serious chance of getting rich, or at least comfortable, through hard work). Twenty years ago, programmers from middle-class origins could actually raise venture funding without relying on (upper-class, connected) “advisors” and extraneous business co-founders who’d charge several percent, and want to manage, just for introductions to investors. Twenty years ago, housing was affordable in the Bay Area, and living on a low salary to pursue a dream was legitimately possible. Twenty years ago, startups fired good employees as often as they do now, but they offered genuinely positive references and introductions to investors when they did so. The attitude was, “We need a different skill set than what you have, but we’ll make sure you land on your feet.” It was more like a rock band breaking up over genuine creative differences than a person being singled out and humilated. Twenty years ago, while it was rare that a startup would explicitly pay for an engineer’s career advancement (2-4 conferences per year was standard, but tuition reimbursement was rare) engineers had the authority to define and self-allocate their own work, so they actually could advance their careers without above-normal assistance. Twenty years ago, there was just as much volatility in day-to-day employment as there is now, but the Valley was still run by lifelong technologists who identified themselves as engineers, not talentless hacks self-identified as future rich people who had ethical license to do whatever they wanted because they were “changing the world”. More often than not, the engineers in that time looked out for each other. It was a different time, and a better one for the Valley.
Second phase
Silicon Valley has devolved in a number of ways. Housing has become inordinately expensive, with California NIMBYists opposing high-density housing at every turn. (“California: where the future is built by people living in the past.”) The result of this is that a typical software engineer, making about $120,000 per year, an amount that would still be considered high in most of the U.S., can end up living paycheck-to-paycheck. What made Northern California great in the 1960s to ’80s has become its downfall: its openness to the new. As a region, it was too trusting. It allowed non-resident third-world despots and corrupt officials to buy real estate that they’d rarely or never use, pricing Americans out of their own housing. Worse, when smooth-talking East Coast financiers took an interest in the region in the 1990s, it welcomed them, unaware that they’d eventually take the place over and out-compete the lifelong technologists for venture capital. The Battle of Palo Alto has been lost.
No one can reverse the arrow of time. We shouldn’t look to restore the Silicon Valley of 1975, because it doesn’t exist anymore, and it never will again. We should be focused on creating something better in 2025. At that, we have a chance. Of course, we need for a substantial number of lifelong technologists to regain money and power. With the U.S. middle-class falling to pieces, this is not going to happen without opposition. There is not a rising tide, and all boats are not being lifted. We, the lifelong technologists and engineers, have to wrest power from the existing elite. We have to do something that engineers (and middle-class Americans, overly steeped in outdated concepts of meritocracy and fair play) generally hate to do: we have to get political. After all, an unreasonable aversion to political activity supports the status quo and is, therefore, political already.
‘Cause the takers gonna take, take, take, take, take, and the makers gonna make, make, make, make, make…
Ayn Rand’s fan club loves to use the rhetoric of “takers” and “makers”. I generally dislike this distinction as it is commonly used, since the “taker” label is usually applied to the poor and uneducated who, through no fault of their own, have little to offer society. Yet it’s illuminating, specifically because it shows Rand’s view of corporate capitalism to be fundamentally incorrect. To Rand, the entrepreneurs were the “makers”, while she assigned the “taker” label to the poor, disenfranchised, and disliked lower classes as well as to government bureaucrats. In reality, the takers are the private-sector social-climbers who, being better at social and political machination than those doing the actual work, capture most of the value generated by the productive but politically disorganized makers. In most companies, the high-status positions are owned by blue-blooded, 100x takers (well-positioned, unaccountable executive bureaucrats) and the all of the work is done by underpaid makers who “just want to do good work” and (to their detriment) refuse to “get political”.
As the takers move in to technology, and out-compete makers for attention and resources due to their single-minded focus on political victory above creation, they destroy its innovative capacity, replacing creativity with mean-spirited, zero-sum slagging. They’ve introduced stack ranking, which is the epitome of zero-sum squabbling. They’ve created an age-discrimination culture that values deference to authority over experience. They’ve replaced a mindset of exploration and value creation with the anti-intellectualism of the enterprise Java shop. They’ve done so much damage that anything that reduces or challenges their power deserves serious consideration.
At this point, there is probably nothing that could be lost in bringing the unions into Silicon Valley.
Objections to unionization
There are four main objections to unionization of Silicon Valley engineers. I’ll address each of these.
1. Unions pit management and labor against each other.
This is the easiest of the four to destroy. With stack ranking in place in companies like Amazon and Google, and with 0.02% slices of 100-person startups qualifying for “ownership” (as in, “you should work 90-hour weeks and carry a pager because you’re an owner“, which is a bald-faced lie) in the Valley, labor and management are against each other. “Class war” is already happening, but it’s one-sided as the working class refuses to defend itself (yet). An engineer is far less likely to advance to the investor ranks in the Valley than an associate in an investment bank or law firm is to “make partner”. Ruses and phony promises, instead of career investment, are deployed to encourage young engineers to work 90-hour weeks on other peoples’ ideas. Management started the fight, and it’s winning hand-over-fist. Equalizing, in this fight that’s already underway, just makes our position better. Collective bargaining may not be the only tool that might allow us to equalize, but it’s a historically proven one.
Improving software engineer wages will also transfer future income away from socially well-connected takers and back to makers. This will give us the capital to fund whatever happens after the ossification of the VC-funded world in Silicon Valley is complete. Oddly enough, even if unions diminish innovation in the companies where they’re implemented (and I don’t see a good reason to believe that they will) they wound enhance innovation in the broader economy by reviving the middle class, and making it possible again for people of average means to capitalize new companies.
2. Wage normalization/mediocrity.
Some unions regulate wages to a degree that most software engineers (including me) find unreasonable. Public school teachers’ unions, for example, make it difficult to fire incompetents and often impossible to pay great teachers what they’re really worth. Though unions improve the aggregate wage, their reputation is for pulling compensation to the middle. This is a genuine problem that we’ll have to deal with. How do we prevent across-the-board mediocrity in compensation? Whatever collective bargaining structure we create for engineers, it shouldn’t prevent one who is genuinely worth millions per year from making that much. I’d like to see a salary floor set, but there shouldn’t be a ceiling.
There is, oddly enough, good news on this item. To tell the truth, wage normalization has already happened in the Valley. An entry-level software engineer at a large tech company will make about $120,000 per year, all-in. If she works her ass off for ten years and becomes 5 to 25 times as valuable, she’ll be lucky to make more than 1.5 times that. With ten more years, she’ll be lucky if she’s not starting to face age discrimination. Employers know that becoming and staying a “10x” engineer requires continuing access to high-quality work, which they make artificially rare (closed allocation). This makes it awkward and difficult for a Staff Engineer to ask for appropriate pay: sure, she’s adding tens of millions per year of value to the company, but that’s because the company is “generously” giving her decent projects!
In other words, we don’t have to worry about unions introducing wage normalization. It’s already there. Most “10x” engineers get mediocre wages, relative to the value of their contribution, already. Sure, there are engineers who make $750,000 per year plus stock options, but (a) that’s extremely rare, and, (b) it often has more to do with managerial favoritism than merit. Software engineers aren’t abnormally high, and they are certainly not “inflated”, for 99 percent of us. For most of us, downward wage normalization has already occurred. If collective bargaining can deliver upward normalization, we should take it.
3. Seniority.
Airline pilots’ unions are notorious for the toxic culture existing around seniority. That is certainly a thing we should not replicate. The pilots who’ve been with the airline get the best routes and make large sums of money ($200,000 per year and up) while the junior pilots make the worst routes and make very little, and this is by contract. These sorts of seniority systems are immensely damaging, both to the airline’s ability to sustain itself as well as to the quality of service, and undesirable even for most pilots. First, they make it a disaster for a pilot to be laid off, because it means starting again at the bottom of the queue. Second and relatedly, they make it nearly impossible for pilots to change airlines without damaging their careers. Third, this sort of overvaluation of seniority leads to mediocrity, because it allows the most experienced people to rest on their laurels. Fourth, while it seems to protect old hands, it also discourages people from moving into that career later in life, because they know they’ll never be able to get the good jobs. In truth, these sorts of seniority systems are a form of aggressive age discrimination, because they lock out mid-life career-switchers who might bring in new blood and knowledge from other domains.
Silicon Valley’s startup culture, with its age discrimination culture and worship of youth, seems to be at the opposite extreme. However, I think this is a false dichotomy. This attraction of employers to the young exists because they can be abused. The seniority system and rate-limiting of promotions still exist. It’s just that the employee’s upside has been eliminated, because companies can renege on the benefits that come with seniority. The seniority system itself is still very much in place. It’s just a broken one.
A few years ago, in a job search process, I submitted to a company’s pre-interview code test a solution that, I was told, was one of the three best submissions they’d seen, and this was a pretty prestigious company, so I’d guess that they’d received a lot of code samples. I interviewed and got an offer, which was… for a junior position. Blowing away the code challenge didn’t matter. This ties into a general dislike I’ve developed for code tests and “brainteasers” on interviews. I’m very good at them, but there’s an error rate for anyone, because sometimes a candidate is rejected because the reviewer dislikes the language he chose. If there’s a chance that performing extremely well can bump a person up a rank or two, then I’d be all for these tests. It’d be to my advantage. If they’re just another hurdle to pass, bringing only downside (and that seems, often, to be the case) then I’d prefer to avoid them. Why would I waste time on a code test just to get a junior position?
In the VC-funded world, we see an amalgam of two systems on the topic of seniority. (This is a common theme of corporate capitalism, which exists to deliver the best of two systems– capitalism and socialism– for a well-connected elite and the worst of both to the rest.) If you don’t have the social connections to get funded and acqui-hired, you still have to get into the queue at the back, pay dues, and watch mediocrities get better projects and more opportunities to succeed. So it shares that in common with the decrepit seniority systems: excluding “the 1%”, the young get shafted. On the other hand, the lack of internal promotion (thus, mandatory job hopping) and aggressive performance appraisal (creating noise in the system, because when stack-ranking comes out, no one is safe; it’s like “The Purge”) make it so that everyone has to be prepared to be on the job market at any time. Thus, later in one’s career, the promises of seniority can be reneged upon. Young programmers (except for well-connected– and, increasingly, parentally connected– ones who can become founders) have to contend with seniority systems that become excuses for why they don’t get good projects or to make meaningful decisions and learn a thing or two. But twenty years later, there is no safety net for them and the “Wild West” rules dominate.
4. Lack of innovation and mediocrity.
Unions, in the interest of advancing their workers’ interests, will sometimes generate regulations that can hamper innovation. Is this a concern? It depends. If you aggressively unionized an open-allocation, engineer-driven software company like Valve, it would probably be a change for the worse. If it’s a closed-allocation software company, you lose… nothing.
Some unions cause mediocrity in wages, while some provide general protection and a wage floor but allow market wages. I think it’s obvious that software requires the second type. Sometimes, unions protect incompetent employees. A software union ought to negotiate a guaranteed severance, but not prevent bad engineers from being fired. With regard to the three issues raised above, I think we’ll be able to engineer a collective-bargaining arrangement that prevents those problems. This one, the fourth, is the biggest. Sometimes, in the interest of protecting members’ jobs, unions introduce a lot of regulations that slow down work, and we don’t want that.
If the company uses closed allocation, the “good news” is that there’s absolutely nothing to worry about when introducing a union. Companies formalize closed allocation (with internal headcount limits, official performance reviews, and a prevailing distrust of employees) when they’ve reached a stage at which innovation is (a) de-prioritized, and (b) considered to be a job for executives alone. Once a firm is rate-limiting and restricting innovation like that, it has already decided that it doesn’t need most of its people to be creative. Fair enough, one might say, as there’s a lot of important work that doesn’t need to be innovative. That’s the kind of work over which unions unambiguously succeed. At that point, let’s bring in the unions to make sure that the workers are fairly treated and compensated. If they’re actually paid appropriately and can save money (imagine that!) they might be founders in the future.
Closed-allocation management is such an innovation killer, already, that any loss that might be inflicted by collective bargaining is just a rounding error. If a company has already decided to implement closed allocation, it’s shown that it no longer believes that it needs innovation. It’s probably right. So there’s nothing to lose.
In sum, the feared culture of mediocrity and distributive squabbling won’t be introduced by programmers’ unions. It’s already there, thanks to Silicon Valley’s management.
In fact, a properly structured professional guild is the only way that I can come up with for defeating that mediocrity. If we put a floor on how programmers can be treated and compensated, we can drive the unqualified and desperate out of our industry, which is the first step toward proper professionalization, and we can cancel the projects that aren’t worth a properly compensated engineer’s time. The main reason that so many software engineers are assigned bogus projects is that our salaries are too low. If it cost more to waste our time, we wouldn’t be assigned to the useless work that a closed-allocation shop generates.
Other benefits
I can’t predict the effect that labor unions would have on software engineer compensation. There are too many variables. My best guess is that they wouldn’t increase salaries by very much (possibly 10 to 20 percent, with more improvement at the high end) but that they’d remain at 2014 levels, even after the current tech bubble bursts. Unions might seem unnecessary in a time when mediocre engineers can earn $140,000 per year, but there’s no reason to be sure that salaries will stay at that level, even for the strong engineers who are worth several times that in any economic climate. We ought to start organizing now, rather than waiting until we ostensibly need to.
Moreover, there are other gains that would improve software workplace cultures immensely. The fact is that, since most of us will never experience the one-in-a-thousand upside outcomes of “fuck you money” or direct promotion to partnership ranks at Sequoia, we’re better off to abolish the Wild West employment culture that exists now. It would be tolerable if it delivered real upside and autonomy to us, but it doesn’t.
Here are some specific protections we could get through a union:
We could destroy stack ranking and mandate that performance review histories not be part of a company’s internal transfer process, eliminating a large class of professional extortions and bringing companies closer to the open-allocation ideal.
We could put an end to exploitative terms in employment contracts such as binding mandatory arbitration, employer ownership of side projects, and one-way non-disparagement clauses that exist only software engineers are too trusting and many don’t read their offer letters beyond the salary and title. (Yes, I agree that it’s “their fault” when they get shafted because they didn’t read their contracts. But it’s unfair that the wiser among us have to compete with these clueless fuck-ups in a race to the bottom.)
We could require employers to allow employees to have representation (legal and career-coaching) in the room when negotiating with management regarding performance appraisal, terminations, references and introduction clauses.
We could reduce the incidence of back-channel references, blacklists, and “no poach” agreements by setting up a union tip line, and by providing legal assistance to victimized employees.
We could have matters of negotiation that are embarrassing for the individual, such as those surrounding disability accommodation, workplace privacy, severance and performance appraisal, managed ex ante, for all of us, by experienced professional negotiators.
We could eliminate (or, at least, curtail) the sharing of HR data, such as salaries, titles and performance reviews, across companies (typically, into third-party “data collection” services), a probably-illegal practice deployed to reduce salaries and to blacklist suspected unionists.
For freelancers and entrepreneurs, we could eliminate the “we’ll call other clients/investors and turn off unrelated interest” class of professional extortion that is often used against them.
Only an insane person would see the above protections as undesirable. They’re necessary for economic and cultural reasons. It’s astonishing and barbaric, for example, that a software engineer can be put on a PIP without the right to have a representative (including, if he wishes, an attorney) in the room with him when that notice is given. We ought to fix that. It’s not just an issue of finding the right price point for our labor; it’s a critical moral issue that we ignore at our peril.
Where to look next
Professional athletes have unions, and have not experienced wage normalization. Their work and rewards have not been drawn to mediocrity. They still compete incredibly hard against each other. The same, I would argue, applies to Hollywood. It’s heavily unionized, and yet, the product is far from mediocre. (Some might dislike much of what Hollywood produces, but in terms of success on the global market, the U.S. entertainment industry excels. On its own measurable terms, the product isn’t mediocre.) Rather than producing mediocrity and stifling innovation, these unions serve to protect workers (and their careers, and their reputations) in a complex, hit-driven business where talented individuals can add immense value, but in a way that’s hard to measure. Software is also a complex, hit-driven business of the same kind, and we deserve the same protections. We have a need to protect our reputations and health, and to avoid being “type-cast” and losing our personal brand, and we have the right to representation that enables us to do so.
I don’t know the inner details of Hollywood’s unions and I can’t say, with any real confidence, that their model is perfect or right for us. I’m not sure. I will say this much: that would be a place to start looking. We have several counterexamples to the “unions produce mediocrity and kill innovation” argument that is made every time someone discusses collective bargaining for software engineers. These give us starting points for this exploration.
Is there an alternative?
I’ve established that nothing is lost in unionizing a typical, closed-allocation software company. The failings and corruption risks of unions are minuscule in comparison to the proven failure and corruption of typical corporate management. If your company uses stack ranking (to my knowledge, Google still does and Amazon does) then you should unionize it. Just killing off stack ranking will show the men upstairs enough momentum to properly scare them. That would be a heroic start.
With regard to open-allocation, innovation-friendly technology companies, I’m less convinced that unions are necessary. Some of the protections I’ve described are owed to software engineers in any context, but a company that commits to open allocation is already offering many of those. The few companies that offer constitutional protection against misguided management– and I’m not talking about vague platitudes about not being evil (directed at Microsoft, which abolished stack-ranking, while Google still has it) or “20 percent time” policies with no teeth– may not be in need of unions. The most progressive ~1 percent of technology firms are already providing much of what unions are there to deliver.
If you’re a technology manager or small business owner and you don’t want the need for unions to exist, the best strategy is to adopt a transparent and constitutional style of management. I’ve studied open allocation a fair bit, and for technical innovation, it is the only solution within current knowledge. The fear I have with regard to the concept is that, in the future, it might be bastardized like “agile” or “object-oriented programming”. After all, “open allocation” is, itself, just two words. It’s the spirit behind the concept that is important. A more general, infrastructural ideal with much broader applicability is constitutional management. Some companies have an “Employee Bill of Rights” that can only be modified by a secret-ballot majority vote. That’s the kind of thinking that a technology company needs if it wants to avoid the need for a union.
However, expecting progressive management to take back the Valley is not, sadly, realistic. It’s time to give up the dream of a return to the 1970s-era middle-class, union-free Silicon Valley, because that’s not going to come back; and to disabuse ourselves individually of the notion that an engineering position at a VC-funded startup is 3 years’ distance from being a well-funded CEO, because it doesn’t work that way either. Collective bargaining may be just a starting point, and maybe it’s not the final right answer, but it’s time to explore the concept.
