On the supposed aversion of software engineers to “the business”.

There’s a claim that’s often made about software engineers, which is that we “don’t want anything to do with the business”. To hear the typical story told, we just want to put our heads down and work on engineering problems, and have little respect for the business problems that are of direct importance to the companies where we work. There’s a certain mythology that has grown up around that little concept.

Taking a superficial view, this perception is accurate. The most talented software engineers seem to have minimal interest in the commercial viability of their work, and a rather low level of respect for the flavor-of-the-month power-holders who direct and supervise their work. It’s easy to conclude that software engineers want to live in an ivory tower far away from business concerns. It’s also, in my experience, completely incorrect. Business can be intellectually fascinating. As I’ve learned with age, new product development, microeconomics and game theory, and interpersonal interactions are just as rich in cognitive nutrition as compiler design or random matrix theory. I might prefer to study hard technical topics in my free time, in order to keep up a specialty, but I’m a generalist at heart and I don’t view business problems or interpersonal challenges as inferior or “dirty”. More to this, I think that most software engineers agree with me on that. We’re not ivory tower theoreticians. We’re builders, and as we age, we begin to respect the challenges involved in large projects that present interpersonal as well as technical challenges.

So why are so many talented software engineers seemingly averse to the business? Why do most talented programmers fly away from line-of-business work, leaving it to the less capable and credible? It’s this: we don’t want to deal with the business as subordinates. That, stated so, is the truth of it.

There are a few who protect their specialties with such intensity that any business-related work is viewed as an unwanted distraction, and I’m glad that they exist, because the hardest technical problems require a single-minded focus. I’m not speaking (not here and now, anyway) for them. Instead, I’m talking about a more typical technologist, with an attraction to problem-solving in general. Is she willing to work for “the business”? Of course, but not as a subordinate. If she’s going to be called in to mix business concerns with her work, she’s going to want the authority and autonomy necessary to actually solve the problems put in front of her. It’s when working with the business doesn’t come with these requisite resources and permissions that she’d rather slink away and build interpreters for esoteric languages.

The stereotype is that software engineers and technologists “don’t care” about business problems. The reality is that they avoid working on line-of-business software because the position is inherently subordinate. Give them the authority to set requirements, instead of coding to them, and they’ll care. Make them partners and drivers instead of “resources”, and they’ll actually give a damn. But expect them to interact with the business in a purely subordinate role, as in a typical business-driven “tech” company, and the talented ones (who are invariably smarter than the executives shouting orders, but have chosen not to participate in the political contest necessary to get to that level) will hide from the front lines.

If a company views software engineering as a cost center, and programming as a fundamentally subordinate activity, it will find that talented programmers avoid direct interaction with the business (which will, by design, happen on subordinate terms) and software it builds will either be of low quality or irrelevant to its business needs– because those who have the ability to write high-quality software won’t even bother to make their work relevant. However, this pattern of degeneracy (although common) should not be taken as a foregone conclusion. There are more similarities than differences between business problems and engineering problems, and it’s quite possible to give people with programming and engineering talent the incentive to learn about the business. While technical talent flies away from “business-driven programming” like a bat out of hell, there’s no intrinsic animosity between programming talent and “the business”. To the contrary, I think that people with experience solving these two classes of problems could have a natural affinity, and have a lot to learn from each other. Any such meeting has to come on terms of equality, however. If working with the business means doing so as a subordinate, then no one with technical talent will do so in earnest.

The back-channel culture, Silicon Valley’s war on privacy, and the juvenility of all of this.

One of the more execrable Silicon Valley institutions (and it’s not like there’s a shortage of moral failures in the contemporary Silicon Valley) is the “back channel” reference call. This is when a prospective employer or investor circumvents the candidate’s provided reference list and calls people who weren’t volunteered. While it’s morally acceptable for certain kinds of government jobs (e.g. in a security clearance) because national security is stake (and because back-channel reference checking is a well-published part of the clearance process) this is just plain obnoxious, unprofessional, and often unethical when done for regular office jobs, where human lives aren’t at stake. It’s bad for job seekers, but also bad for the people being called, who may have never volunteered to give references in the first place.

Unfortunately, the technology industry is full of unprofessional, juvenile man-children who don’t seem to know, or care, about professional protocols. So this conversation actually has to happen, and it will happen here. But, for us as a community, it’s an embarrassment that I’m writing this. It’s like when tech conferences have to publish anti-harassment policies. Shan’t we be embarrassed, as a community, that not all of our members know that groping strangers is not OK? We should, and for this issue, likewise.

Why is back-channel reference checking so bad? I can think of four reasons to despise this practice.

It violates an existing and important social contract.

When someone applies for a job, there’s a social contract between the candidate and the company. The candidate is, under this contract, expected to represent her qualifications truthfully, and the company is expected to evaluate her in good faith.

A violation of this contract would be a company that has no open positions, but holds interviews to get proprietary information about its competitors. That’s not “good faith” because the candidate has no chance of being hired. Her time is being wasted, in order for the company to get information. That does happen, but it’s generally considered to be a slimy practice, and it’s hard enough for a company to keep the secret that it’s uncommon. Back-channel reference calling is another, similar, violation of the social contract. A company that extends an interview is representing that (a) it has the resources to hire, and that (b) it will hire the employee if the employee’s total packet (CV, interview performance, and furnished references) performs sufficiently well. To do otherwise is to show a complete lack of respect for the employee’s time. This implies that if a candidate is rejected, it ought to be something in the official “front channel” package that was the reason.

How much feedback should be offered to rejected candidates is, ethically, an open question. I doubt that it’s reasonable to expect an employer to take time to explain exactly where in the interview a candidate failed, because that can lead to fruitless and mutually demoralizing discussions. Many companies refuse to provide explanations, for that reason. I will maintain the ethical obligation of the employer to communicate (sometimes, passively) what stage the failure occurred at. If the candidate isn’t called back, it was the CV. If the candidate gets an interview but nothing else, it was interview performance. If the candidate is asked for references but doesn’t get an offer, then he needs to consider a different set of people the next time he gives references. Injecting other “secret” stages into this process just adds noise to the feedback. While I don’t consider companies responsible to communicate the exact reasoning behind their decision, using a process that obfuscates existing feedback is a breach of professional ethics.

For a concrete example, let’s say that a candidate gets to the stage of furnishing references and volunteers a few, and they come up positive. Then a few back-channel references are called, and something negative comes back. It doesn’t matter if it’s untrue or if the person isn’t a credible source; the candidate’s probably sunk and, of course, he probably won’t be told that it was a back-channel reference that did him in. Now his relationship with three of his closest professional colleagues is needlessly and wrongly complicated.

Back-channel reference checking also has a way of getting back to the candidate’s current employer. Plenty of defenders of this practice say, “Oh, I’d never do that.” Bullshit. If you’d reject an otherwise stellar candidate based on unreliable back-channel feedback, then you’ve already proven that you can’t be trusted to be “careful” with peoples’ careers. Back-channeling publishes a possibly private job search (yet another violation of the social contract) and word travels fast.

I think that, in the long run, back-channel reference checking is actually quite expensive for companies. Savvy candidates, when dealing with companies that use the practice, are going to fake competing offers in order to put time pressure on employers and prevent the back-channel cavity search from happening. (It violates the social contract for a candidate to lie like that, but if the contract’s already broken, why not?) That will lead to hasty decision-making, compromise the existing hiring practices, and result in costly mistakes.

It’s a show of power and aggression.

It takes social access to get into a stranger’s past at any level of depth. People don’t like giving references unless they’ve agreed to be a reference for someone, and back-channel references never knew that they were references (and may take personal offense to not having been asked first, not knowing that their names weren’t volunteered). HR officials at companies, often, will only verify basic details about previous employees, knowing the legal risks of giving anything more. Likewise, most people who are asked out of the blue for a reference aren’t going to give one to just anyone. They have to trust the person asking. Back-channel cavity searches require knowing a lot of people. They’re easier for large corporations which can involve a lot of people, or for venture capitalists who’ve been buying and selling influence for decades, but pretty much impossible for the little guy to use.

When VCs claim that back-channel reference checks (currently legal, but let’s hope that Washington becomes aware of the issue and does the right thing) are critical to their business, what they’re actually doing is gloating about having the social resources necessary to conduct such investigations. It’s hard to get people to volunteer information that is often inappropriate for them to share. “Do you feel like fucking over a random stranger?” “I really want to know if Sue is of the future-pregnant persuasion; does she talk about kids a lot?” “Tom didn’t put dates on his CV; can you tell me his approximate ‘graduation year’?” “Give me a rundown of Mark’s health-problems-I-mean-‘performance’-reviews from 2008 to 2013.” “Is Angela one of the ‘political’ Native Americans or is she just like anyone else?” People don’t answer these questions, asked cold by strangers with no skill at interrogation. It takes resources (mostly, trust and contacts) to get it.

Often, the person who does the back-channel reference check will admit to doing it. When it results in rejecting the candidate, the failure is more silent, but often it results in further “conversation”, the purpose of which is to humiliate the candidate (reducing her likelihood of negotiating for a higher salary or better job role than the company is prepared to give her) under the guise of addressing “concerns”. At that point, it’s about showing utter dominance by waltzing into that person’s career, turning over all the furniture, and using the toilet without flushing. It’s to impress the target with the godlike ability to get access to all sorts of inappropriate information. It’s a way of saying, I don’t have to play by the rules, because I’m powerful enough to get away with anything.

It’s invasive.

That Silicon Valley’s back-channeling is invasive hardly needs explanation. There’s a general protocol around what is and is not appropriate for a prospective employer to research. Running a background check to make sure the person worked at the companies, and attended the schools, that she said she did? Totally OK. Finding out that she has kids, showing up at their elementary school unannounced to observe them, and bribing an unscrupulous principal into getting their academic records, in order to find out if they’re special-needs kids who might be more demanding of the mother’s time than average kids? That’s not OK. There’s a lot of information that is arguably potentially relevant to someone’s future job performance that we, as a society, have rightly decided to be off-limits in making decisions about whether to hire someone.

The “front channel” employment process, at least, imposes some accountability on both sides. The employer communicates its priorities through the questions that it asks, and thereby puts credibility at risk if those priorities are unreasonable or, worse yet, illegally discriminatory. Volunteered references are provided so the employer can validate that the candidate actually worked at the companies claimed and isn’t completely off-base about previous roles and functions within those companies. Using back-channel references is, however, about the more powerful party’s escape from accountability. To ask for information communicates that there is interest in it. To surreptitiously acquire it does not, which means that there’s plenty of room for impropriety and invasion.

It’s also uselessly invasive. The feedback is noisy. For every person with knowledge about someone and his work, there are ten with opinions. Venture capitalists and CEOs who perform these back-channel inquiries may think they’re sharpshooters who can quickly get to credible sources, but they’re not that good. They just never get feedback on their failures, because they’ll reject anyone who doesn’t come up with a perfect bill and never see that person again.

One of the reasons why 2-3 volunteered references (and, at absolute most, 5) has been the standard in employment for so long is that, perhaps counterintuitively, the quality of employee hired doesn’t improve beyond that number. The main reason to check references is to filter out unethical people who interview well, but past 7, you are empirically more likely to hire an unethical psychopath. Why so? Among unethical people, you tend to have two kinds: the petty, untalented ones who make annoying messes, and the talented, dangerous ones (psychopaths, usually) who can take down a whole company. The first category can’t get references; they burn bridges, leave messes in their wake, and are generally disliked by everyone who knows them well. The second category always have glowing references. They have no qualms about making friends pose as bosses, buying references off-the-shelf from made-up companies (yes, this service exists) and “coaching” people into telling exactly the story they want. You can’t actually filter out the second category of psychopath through any social proof system, which means that, after a certain point, your best odds are with not excluding normal people.

If you ask for 10 references, the average, basically ethical, person with a normal career has to dig into his third string and at least one of them is going to be less impressed with him than he expected, so he’ll fail. The psychopath, however, will always pass the 10-ply reference check. That applies even moreso to back-channel references, because psychopaths hide in plain sight and great at intimidating other people into acquiescence. The psychopath might have enemies and detractors, but it’s not being disliked that ruins a person’s career, but low social status (by the way, “performance” at 95% of jobs is social status). Psychopaths make sure that any slight against their social status is swiftly punished, often having loyalists in every social sphere they’ve inhabited. So the back-channel reference check, counter-intuitively, strengthens the psychopath’s power. Some of the people called will dislike him, but not a single one will diminish his social status in any way, and this will strengthen his image as a powerful, “high-performing” person and deliver him the job. Psychopaths really are like cancer cells, able not just to evade human “immune systems” built on social proof and reputation, but often to co-opt those for their own purposes and weaponize them against the good. How to beat psychopaths is a complicated topic for another essay; the best strategy is not to attract them. One of the major reasons I champion open allocation is the specific fact that such an environment is unpalatable to the workplace psychopath.

The invasiveness of the back-channel reference check, empirically, delivers no investigative value about what actually matters (ethical character). It drags up a lot of “juicy” (meaning “inappropriate”) gossip, though. That is why, in a world of oppressive, inane juvenility like Silicon Valley, they’ll probably never go away entirely. It’s too much “fun”, for a certain species of manchild that the Valley has given undue power, to invade a stranger’s personal and professional lives.

At any rate, reference checks aren’t actually investigative in purpose. The real purpose of reference checking is to keep the moral middle classes– people who aren’t unethical psychopaths, but probably would lie a bit to improve their careers, if they weren’t afraid of getting caught– honest. At that, it’s probably a necessary evil, and I think it’s fine for employees to ask for 2-3 (hell, even 5) references to validate that the employee’s represented career history and qualifications are correct. If references were never checked, then people would inflate their qualifications more than they already do, and that would add noise to the job-search process. The reference check has legitimate value in verifying the correctness of a candidate’s claims. This doesn’t justify an adversarial invasion of privacy.

It’s discriminatory.

For those who rely on back-channel references, one of their favorite reasons for doing so is access to all sorts of information that can’t be requested in the “front channel” process, relating to age and health issues and pregnancy history and socioeconomic status. Off the bat, the discriminatory intent is obvious.

There’s more to it, though. Right now, in 2014, venture capitalists and technology employers have an almost pedophiliac attraction to youth, especially when it comes in the package of a sociopathic frat boy. It’s not really about chronological age. Rather, they like people who haven’t been challenged yet, with stars in their eyes and a general cluelessness about the world. They champion “failure” because it benefits the VC for the founders to take risks that would be considered irresponsible by anyone who’s had enough life experience to see what actually happens when one fails. Also, there’s a vicarious nostalgia in play: VCs want to be reminded of the time when all they worried about was drinking and getting laid, before the jobs and the kids and aging parents. Instead of being honest about their midlife crises and buying Ferraris or boats or marrying trophy wives, they’ve taken the midlife crisis in the form of a hilariously underqualified protégé (like Lucas Duplan or Evan Spiegel) made “startup CEO” by their own largesse (and, given the Valley’s culture of co-funding, connections to other investors). This, dear reader, is what “culture fit” at startups is really about. It’s about socioeconomic and cultural homogeneity, and isolation from the challenges of the real world (kids, aging parents, health issues). It’s college for people who were too socially incompetent in their late adolescence to make the most of that stage of life when they were in it, and who want a retry in their young adult (or, for investors, midlife) years.

People who’ve been challenged, and how know that there are actual stakes in life, don’t like back-channel reference checking for the same reason that they don’t like open-plan offices. If you’ve ever had a serious health problem, the added stress of having it in front of 50 other people is just intolerable. With age and challenge, people become far more competent in general but lose a bit of endurance with respect to the weird and mostly minor (but cumulative) cultural insults of the open-plan, juvenile, “startup” culture with its lousy health benefits, blurred lines between personal and professional life, and general lack of respect for established professional protocols that form out of decades of experience. If this heightened desire for privacy doesn’t happen for any other reason, it certainly happens when people have kids. Why so? The college bubble is an artificial world whose socioeconomic heterogeneity is enforced in order to create a culture of ubiquitous trust. You don’t need to worry about each person individually, because the “adult supervision” of the admissions office has already done that. The “hip” tech culture is all about preserving that youthful attitude (“I don’t need privacy because there are no really bad people around”) toward life. However, in reality, the world is dangerous and has lots of evil people in it (even at colleges, but that’s swept under the rug!) When people have children, the biological and emotional need to protect another creature makes it impossible to harbor that prevailing, universal trust. If you have to protect someone else’s life, you can’t trust everyone. And open-plan offices (more specifically, visibility from behind, or “open-back visibility”) are about forcing the employee to render trust to the whole office. The same holds for back-channel references, but in that case, there’s even less consent. If you think back-channel reference checking is morally acceptable, then you’re arguing that people should be mandated to trust complete strangers in their own careers.

The truth about privacy and protocol is that they’re not just there to protect “the weak” or people “who have something to hide”. To want privacy doesn’t mean you’re doing anything wrong. It just means that you’ve had enough life experience to know that not everyone can be trusted with all information. I’m well aware of the fact that my tone, on issues like this one, sounds unduly adversarial to many people. I don’t actually see the world in adversarial, zero-sum terms. The world ought to be mostly cooperative, and I think that it is. However, I recognize that a large number of interactions and transactions are innately adversarial, and I’m old enough to know that even people who’ve done nothing wrong have a desire for (and a right to) privacy.

Privacy and the lack of it

College is a time of life in which people relinquish some privacy because there is “adult supervision” that is supposed to prevent things from getting too far out of hand, and because people of low socioeconomic status (presumed to be where criminals come from) are generally excluded, unless they’ve been vetted heavily for intellectual ability as well as good behavior. In the college bubble, most students don’t have to work outside of their studies, and most students’ parents are in their 50s and at the peak of their careers (not 35-year-old single mothers who gave birth to them at 17, not 82 and dying). Excluding managed intellectual challenges in coursework, most of these people have never been challenged… and those who have either don’t fit in or become others’ “diversity experiences”. If this is an uncharitable depiction, let me admit: this isn’t entirely bad. It’s the “magic” of socioeconomic protection and age heterogeneity that enables people who met in September to be “best friends” by October, and feeling safe to discover alcohol and sex and psychoactive drugs and politics and computer science around such people– in a world where privacy is relaxed and people get to know each other quickly– is a big part of that. The suspicion and chaos and status-assessment and busyness that characterize “the Real World” haven’t set in yet, in the sunny college bubble, and that allows deep friendships to form in a month instead of over years. Yes, I can see the appeal of being 18-22 forever.

“Culture fit” and the Valley’s worship of youth are outgrowths of this desire, which many share: to create a world in which it’s possible not to grow up. (If one wonders how the adult supervisors, like VCs, benefit by running a silly camp for overgrown adolescents, the answer is that people who aren’t expected to act like adults won’t demand to be paid like adults, and the VCs can make out like bandits. Considering that, they actually charge a bit more than college bureaucracies.) One of the reasons why the consumer web contingent now dominating the Valley simply doesn’t get peoples’ need for privacy is that it, collectively, is still stuck at a mental age around 23 and, more specifically, in the mindset of a certain type of 23-year-old who’s never been challenged or tested. (Obviously, I do not intend to apply the “never been tested” label to all people at that age, or at any age, since it wouldn’t be accurate or fair.) They don’t have to be white, male, young, heterosexual, childless and from upper-middle- or upper-class backgrounds but, for statistical reasons, they usually are.

Back-channel reference checking becomes, if not morally acceptable, more understandable when one realizes how juvenile private-sector technology has become. I’ve lived in the Real World and I’ve definitely had legitimate challenges: deaths in the family, personal health issues, lost jobs and even a couple 3-4 month spells of unemployment. I’ve seen enough to know that the stakes in this life are fucking real. There’s no Dean of Students who sits down and talks the bad things out of happening. You don’t go in front of a Financial Standing Committee if you lose all sources of income; you actually suffer. As such a person who has actually lived in the world, and seen what it is, and learned that it is pure idiocy to trust literally anyone into one’s career via “back channel references”, I am vehemently against the practice. And I am morally right. However, there are exactly two types of people who can be ethically OK with the increasing prevalence of back-channeling in technology: (1) powerful sociopaths who’ve decided that the rules no longer apply to them, because their getting away with something is proof that it’s OK for them to do it, and (2) clueless naifs who’ve never suffered or been challenged… yet. To people in college mode, a back-channel reference check is no different from asking, “Hey bro, how many guys do you think Monica has slept with?” That is, it’s very inappropriate, but not the sort of thing that would lead to a seven-figure lawsuit or a jail sentence.

More generally than this, I think that people become more private and discerning as they grow up. When you’re six, you’ll be friends with that “funny” kid who puts dog poop on a stick, holds it front of his face, and laughs at it. When you’re 31, if you’re like me, you’ll have a hard time making conversation with people of average (or even 90th percentile!) taste and cultural awareness. This isn’t all good. I spend a lot of time trying to figure out how to crack barriers in a meaningful way and, given my average-at-best social ability, don’t always know how to do it. I’m glad that there are people like the 20-year-old (as of 2004) Harvard student Mark Zuckerberg who can get insights into these problems and, at least in some partial way, solve them. College is too “open” for that mentality to work outside of a socioeconomically heterogeneous bubble– we’d have to become a Scandinavian socialist country for the college mentality to work outside of an academic bubble, and I don’t see that as politically palatable in this country– but the “adult world” is a bit too closed, cynical, and cold. In many ways, I see the appeal of the former, and I think the ideal point is somewhere in the middle. (The world would be less closed and frigid with less socioeconomic inequality, but I’m not anywhere close to having control over that variable.) That said, I’m a realist. Trusting strangers unconditionally in one’s career is just plain stupid at any age. Not everyone in this world is good, it doesn’t take much effort or luck for the bad people to make themselves dangerous, and the stakes are too fucking real to pretend they don’t exist.

We, the fully-fledged adults, might seem cynical, stodgy, and adversarial when we tell Silicon Valley man-children that their fratty back-channel reference calls aren’t OK, or that they should stop putting sexist humor in slides about their products, or that open-plan offices are a back-door age and health discrimination that we find crass, or that they need to stop betting their companies on the (extremely rare) clueless young thing that gives his all to a company that gives him only 0.05% of the equity (because, honestly, most of those people aren’t talented, just young and eager). We’re not. We’re just experienced. We know that privacy, protocol, and propriety are actually important. We’ve seen people suffer needlessly due to others’ stupidity, and we’ve learned that the world is a complicated and difficult place, and we’re trying to defend the good, not just against the evil, but against the much larger threat presented by the mindless and immature.


The predominant culture in Silicon Valley has moved against privacy, with personal and professional lives bleeding together, frat culture (and its general disregard for propriety) invading San Francisco, and back-channel communication becoming part of the hiring process, all in the name of “culture fit” (preserving the college-like bubble). This is not the only culture in technology, and it’s certainly not moving in unopposed. Sadly, it does seem to be winning. Demanding privacy at a level previously taken for granted (even asking for quiet working conditions and a barrier at one’s back) has become unusual, isolating, and embarrassing. The attitude that it often meets is, “Why do you need privacy if you’re not doing anything wrong?” Only political naifs consider that question to be remotely reasonable to ask. Everyone needs privacy, because the world is complicated and dangerous and trusting the whole world with all of one’s information is just reckless. This isn’t Stanford. This is real fucking life.

The end result of this is an exclusionary, insular culture of an especially pernicious sort. Silicon Valley’s oppressive mandatory optimism and its contempt for privacy and those who demand it aren’t just classist and sexist and racist and ageist. In fact, Silicon Valley doesn’t have a coherent desire to be any of those things. It’s about a rejection of experience. To live in that sort of college-like bubble, you have to reject the knowledge that not all people in the world are good. You have to accept intrusions against your privacy and person like open-back visibility at work, micromanagement in the name of “Agile”, and back-channel reference calls. You have to have never been challenged or tested, or at least seem like that’s the case. However, that puts us, as an industry and community, far away from the realities of human existence. It makes us, just as we are ethically and professionally reckless as shown in our use of back-channel references, out-of-touch and dangerously oblivious to what we are actually doing to the world.

We have to take stock of this and change course. No one else is going to do it for us. It’s up to us to lead and, to do that, we have to grow the fuck up.

Leadership is not a stepping stone

This line of thought was inspired by a tweet from Carter Schonwald:

To which I replied…

These aren’t new ideas, from me or in general. Savvy people in technology have begun to realize that much of what’s getting funded isn’t deep, infrastructural technology, but the audition projects of well-connected, mid-level product managers trying to make their case for “acqui-hire” into a junior executive role at a large corporation, or, better yet, a position in venture capital. No news, right? It’s an old topic. Let’s not beat it to any more deaths than it’s already had.

Yet I realized that, of all the con games going on in the VC-funded consumer-web ecosystem, this insight gets to the fundamental issue. There’s a dishonesty inherent to a “founder” presenting himself as an entrepreneur, doomed to sail or sink with his ship, when his actual priority is shoring up his reputation so that he gets a better job no matter what happens to the company. This means that, if saving the business or his employees’ careers mandates that he oppose the interests of investors, he won’t (and can’t) do so.

The “founders”– at least the business ones who tend to be tracked naturally into the CEO role– are probably savvy enough to know that they’re really mid-level product managers because the VCs are the real executives of Silicon Valley. They also know that most of them are going to get managed promotions (e.g. acqui-hires or VC jobs) rather than build independent companies. They must know that. The odds already tell that story. For the business “founders” and probably some of the technical ones, the job is just a stepping stone. It’s the technical people, who don’t know as much as they think they do about business, negotiation, or the dominant personalities in this game, who believe they’re building the next Facebook and will throw down 100 hours per week to overcome the deliberate understaffing (relative to expectations) of the venture. Most of the work is done by “true believers”, but the power in and over the company is held most strongly by nonresidents (VC bosses) and transients (business co-founders, connected executives) angling for their next bump up. This leads us directly to a six-word compact objection…

dot dot fucking dot

… Leadership is not a stepping stone.

Ethically, I’m fine with people treating their jobs as stepping stones, to be used to get to something better, because most people are in non-leadership positions. In truth, “stepping stone” is how I’ve viewed most of my jobs, as an impatient person at a high level of talent. If I’m not being groomed for a meaningful position or a major role on an important project, I’ve already got my eyes focused elsewhere. That is, on my part, knowing non-leadership. It’s a peacekeeping strategy: rather than fight for the limited advancement opportunities or executive attention/mentoring or top projects in one place, why not avoid conflict and seek improvement elsewhere, at no one’s cost? I don’t see it as disloyal or “mercenary” to keep an eye out for external promotion. I view it as necessary because it prevents and defuses conflict.

That said, people who are expected to be leaders shouldn’t be treating their companies as stepping stones. It’s one thing to be a manager in the reductionist sense– an officer hired to make decisions pertaining to another’s assets– and take that careerist view. That’s not what executives present themselves as being, however. In most companies, they call themselves the “leadership team” (a gag-inducing pair of words, but never mind that). Founders, as well, certainly present themselves as being tied-to-the-mast leaders. This isn’t quite correct, because while a genuine leader may have to oppose the interests of an individual within the group, they ought to be defending the group against external threats. That’s why people give up their power, as individuals, to leaders: to have a more coordinated and quicker response to external or emergent dangers.

Yet, when there is a conflict of interest between their employees and their investors, founders must choose the investors. Founders know that VCs talk and that the influential ones can shut them down with a phone call. They also know that, if they fail, they need references and introductions from their VC backers. A boss can end your job, but a VC can end your career. Founders have no choice but to manage up, and that’s a problem for the whole system, because managing up is generally the antithesis of leadership.

The truth is that there’s very little leadership in Silicon Valley. While the ability to flit about companies does give talented, reputable engineers more leverage than they would have elsewhere, individual Valley startups are often characterized by intense power distances, and holding political power isn’t the same as leading. “Flat” is often a euphemism for “dictatorial”. Well-run larger companies actually require managers to show some of the characteristics expected of a leader, while startups often take a “my way or the highway”: approach, and use “culture” to back-cast departures as “non-regretted”. These startups generally manage up into the founders, who manage up into “investors” (the true executives of the Valley) who manage up into better-connected investors with better deal flow. Everyone is just trying to get a notch or two ahead. There’s nothing wrong with that– I’m the same way– in general, but it’s not appropriate for people who want others to look to them for defense and direction.

Is management leadership?

Corporate executives like to use “management” and “leadership” interchangeably, but they have almost opposing meanings in many cases. A manager is a person who makes decisions pertaining to an asset that he or she does not own, such as a company or a celebrity’s reputation. They’re almost always going to be selected from the top, by owners of those assets or by higher tiers of management. Genuine leaders are generally selected and elevated from the bottom. You don’t get to decide that you’re a leader just because you have authority or resources. The people being led decide whether you’re a leader. Of course, there is a shared interest between owners and employees that the company sustain basic function, but the alignment often ends there, and the pathetic equity slices that Silicon Valley gives to regular employees (like software engineers) are never going to change that. When this conflict of interest exists (and it usually does) to be a manager requires taking one side, and being a leader requires taking the other one.

A leader can be a manager or not, and a manager can be a leader or not. All four possibilities exist. Managers will often say that they are leaders, but their salaries are paid and their performance is evaluated from above, and they know it. Often, they are at best puppet leaders. Some have the genuine charisma or alignment of interest necessary to be accepted as legitimate leaders (that the group would choose if left to its own devices) and others have the moral fortitude to take their reports’ career needs and long-term goals (personal, financial, and career-related) seriously, but it’s not a requisite part of the charter, and it’s not common.

The middle management problem

This problem isn’t limited to Silicon Valley. Middle management is generally problematic, in this analysis. Most companies can find a place for a lifelong individual contributor. For the highly competent, there’s an opportunity to establish credibility and value without traditional organizational ascent. Management has different rules. Just as there are (by definition) no good poker players who lose money, there are no good managers who don’t rise. If you’re a middle manager for ten years, no one will take you seriously. Top executives won’t mentor you, and you won’t get the most talented reports, because you won’t be able to promote them. If you couldn’t bring yourself to rise against any political headwinds, how can you protect and advance others? As soon as a person steps into a management role, the clock starts. Middle management is an up-our-out role.

This is what VC-funded technology’s age discrimination problem, for the record, is really about. Most of these consumer web startups aren’t technology but marketing experiments using technology. There isn’t enough technical depth to them to justify an individual contributor track lasting more than 5-10 years. That brings the acceptable maximum age for engineers to 30-35 (and for “product” people, it’s even lower). Allowing no more than 5 years in middle management, this requires that people reach the executive ranks (venture capitalist) no later than 40. If a 41-year-old VC partner encounters a 50-year-old “founder” who’s still asking VCs for money, he’s going to wonder what the hell happened. By 50, people should be asking you for money, introductions, and resources.

The severe time pressure that is on middle managers tends to compromise their decisions. They need approval from above to get promoted. That’s not negotiable. As for anyone else in the corporate world; if they do their jobs well, but their bosses dislike them and evaluate them poorly, they still lose. Good will from below, on the other hand, is completely optional. Sure, it’s better and easier to have it, but it can be tossed away in a pinch. If they succeed, they won’t be seeing much of those people in the future, because they’ll be a level or two higher in a couple of years.

In sum, there’s an intractable conflict of interest in the concept of middle management. To be honest about it, I don’t think there’s a solution. Performance evaluation in any job where the results aren’t completely objective is, in truth, destined to be gamed. And most of the work that is perfectly objective is being given over to machines, who work more reliably and cheaply than humans do. For the subjective stuff, those who quickly identify influential people and appease them are always going to rise faster than earnest, uniform high performers. Managing up will always be rewarded more than genuinely leading a team. This is no surprise, in the corporate theatre, to the more cynical among us. What’s more irksome, in contrast against the way that world is presented, is that it’s equally true in Silicon Valley. For all the talk about “vision” and “disruption”, anyone who has the political skill to be a founder knows that whether one’s startup succeeds or fails matters only one-tenth as much as how one’s performance is viewed by investors. If you build a great business, but you’re fired and stripped of your equity and can’t get a meeting with anyone to build your next project, you’ve lost. If your company crashes and 180 employees see their last paychecks bounce, but it’s viewed as not your fault and you get a partner-level position at Sequoia, then you’ve won.

Where this all ends up

Most managers aren’t leaders, because they can’t be. They have to manage up. That is, in effect, their job. I don’t think that “360-degree reviews” fix this problem either, because people they have the power to fire aren’t going to honestly evaluate their performance (not if they’re smart, anyway). The effect, for a middle manager, of failing to manage up, is immediate and brutal: loss of reputation, advancement opportunities, and often the job. The effect of poor leadership is insidious and unfolds over enough time that other circumstances (including external conditions and random events that occur in the mean time) can be blamed. By the time there could be macroscopic damage, visible from above, due to poor leadership; the manager has either been advanced, relegated to terminal status, or fired, all for reasons unrelated to his actual ability to lead those below him.

This means that it will be rare that a middle manager actually leads the group he is expected to oversee. It’s not his fault. His job is defined above him by people with almost no concern with the well-being of his reports. In the Valley, we shouldn’t expect this kind of leadership from founders, either. The only people with the latitude to genuinely lead are the well-connected investors whose names can make or break companies. Of course, since that set of people is selected through a process that values “managing up” as well, it’s only by a rare coincidence when a person is invited who actually has the vision, charisma, or moral perceptiveness necessary to lead. Just as in any other executive suite, 90 percent of them won’t have it, because they’re selected based on other criteria: the ability to manipulate and appease the people above them, and to game whatever system of performance evaluation is set in place.

The lesson of this is that truth is anarchy. If you’re a young engineer, don’t look for leadership. Don’t expect the Hollywood depiction of affairs, where a “mentor” just happens to see where you are and “fix” your career, to occur. It rarely works like that. Most young engineers think that, if they work 100-hour weeks on the low-impact grunt work that they’re assigned, someone above them will “discover” them, ask “Why the fuck are they wasting your time on this shit?”, and fast-track them to better things. That’s far too rare to bet one’s career on it happening. Barring the rare stroke of fortune that might happen once every ten years or so, you have to become your own mentor and advocate, because no one’s going to do that job for you. The few people who do have the credibility to clear away political nonsense, and to create small fields of sanity and protection, are going to want to work with people who’ve done much of their work for themselves. Self-mentoring is the rule, and guardian angels are the exception.

The insight that truth is anarchy, in the corporate world, is an important one. As I’ve grown older, I’ve realized that the few people who can genuinely lead aren’t born with the ability. Personal charisma is superficial. Leading others is largely about providing protection against the chaotic and negligent-to-malevolent world outside: from external competitors (who aren’t malevolent, but opposed in interests) to internal cost-cutters (who compensate for their mediocrity and lack of vision by offering ideas that seem to save money in the short term, while harming the company in the long run). Much of whether one can provide this protection relies on credibility and status, and getting those is always more political than based on merit, but an equally important capability is to know how to create fields of sanity and fairness in an insane and unfair world. The first step is to attempt to create such a thing for oneself, and it’s typical to fail a couple of times before getting it right. I think that, 15 years from now, the people in my age group who mI’ll recognize as the best leaders will be the ones who are currently waking up to reality (“truth is anarchy”) and, rather than being blinded by corporate smoke-screens and phony loyalty, learning how to fight for themselves. To lead is to fight for others, and that’s almost impossible to know how to do, unless one has years of battle scars won in fights for oneself.

Of course, most of the people who get to be executives and founders will be the non-fighters and the company police. That will never change. We just have to find a place where we appear out of their way, and outperform them. Silicon Valley used to be the place to do just that. Circa 2025, it’s going to have to be somewhere else.

This comment was censored by Y Combinator’s Hacker News.

The news topic was Alan Eustace’s recent skydiving record.

The Hacker News comment thread is here.

My comment is here. The link may not work.

Here is the text of it.

Maybe this is cynical but I dislike stories like this. I’m glad he got back safely, but it sounds a bit Everest-y. Felix Baumgartner was an experienced jumper. Every time a corporate executive pulls the “throw money at something hard for mere mortals” card I cringe. Again, Everest. The number of rich businessmen who die because Mother Nature does not give a fuck about job titles is immense.

The comment itself isn’t that interesting. What is interesting is that such a vanilla remark (profanity isn’t taken to be an issue on Hacker News) could be censored. I wonder why? What libertarian nerve did I tweak?

I’m not going to speculate. But enjoy the above, an average, ordinary comment rendered unusual by the mere fact of it being censored.

An insight on how to fix technology’s Damaso Effect

I’m going to start this analysis by focusing on a negative pattern of behavior that seems unrelated to technology’s Damaso Effect.

The Misogyny Loop

I know someone (I’ll call him “Stan”) who’s about 30 and has never been in a relationship that lasted longer than about six months. He’s not unattractive and, while his opinions on many topics are wrong, he’s intelligent and well-employed. He’s even cordial. It’s pretty easy to see what’s wrong with the guy: he’s openly misogynistic. He believes that women are petty, irrational, capricious, emotionally dysregulated and have poor values, and it doesn’t take much to get him to share that opinion.

On one hand, he’s completely wrong. I don’t mean that it’s morally abhorrent (although it is) so much as that it’s just incorrect. Virtually everything Stan believes (or, at least, says he believes) about women and men and the relative value of each is total horseshit. You can’t take it seriously; it will just make you angry. Unfortunately, men who think this way are not uncommon, either in the technology industry or the world at large. Some learn canned social skills to trick shallow, confused women into going to bed with them and call themselves “pickup artists”. Others call themselves “incels” (involuntarily celibate) and stew about their predicament on the Internet. They’re awful to listen to, repetitive in their whining, and generally bad at seeing the real problem. “Hookup culture” is revolting, but pinning it on the women alone is misguided. The general pattern, for these men, is that they take traits of the worst people and project them on to “women”. I wouldn’t be surprised if female misandrists didn’t do the same to “men”. It’s a gender-neutral fact that the sexually and socially “loudest” people are often the worst ones, but they’re also a small fraction of the population. If you let them bias you, you’ll reach bad conclusions.

Stan, when he generalizes to “women”, sounds like an idiot. (If women are irrational and emotional, then why are most crimes committed by men?) Yet, I will give him this: his judgment is correct, over most of the women he’s dated. I’ve met a few of them, and they generally treat him poorly. He dates stupid, shallow, capricious, and damaged women, and this generates negative experiences that reinforce his blighted worldview. Comparing his small group of male friends to an adversely selected set of women, he concludes that men are better people and that women are unfair, capricious, and slutty creatures to be used only for sex. His negative views of woman keep him from meeting normal women (they don’t want anything to do with a guy who thinks women are innately inferior, and who can blame them?) and forming healthy relationships, and thus he falls into a Misogyny Loop. Because his attitudes toward women are abhorrent, he meets and dates damaged women who confirm his biases, and becomes even more entrenched in this negative view of the female sex.

Technology and the Business

I’ve written about the Damaso Effect. Programmers have a tribal dislike for “The Business”, for HR, and for the managers and executives (“pointy-haired bosses”) who pay us. As with Stan’s misogyny, these feelings didn’t emerge out of nothing. The sampling may be adverse and biased (and I’ll get to that) but the experiences are real. For most of us, the businesspeople who manage us are incompetent fuckups. Stack ranking, a textbook example of bad HR that is despised by competent business leaders, is still quite common in technology companies, and that’s because our biggest companies actually are run by a bunch of fucking idiots.

From Harvard Business School, the good students go on to start hedge funds or work on billion-dollar private equity deals, the middling ones get partner-track slots at McKinsey or end up directly report to CEOs of large corporations, and the leftovers get passed to California and boss nerds around. The best of our tribe (software engineers and lifelong technologists) answer to the worst of theirs. It sucks. It’s hard to ignore the tribal hatred that comes out of the humiliation inherent in a skilled programmer being told, by a fresh-out-of-college management consultant, that he has to attach future code-change commits to “user stories”. But let’s try to put any hatred and history aside, and step back. By any definition of the concept of a “business person”, there are competent, smart, ethical ones out there. I’ve met quite a few of them. They exist. They just… don’t come anywhere near our industry. Can you blame them?

Could we be like Stan? Is it possible that our blanket negative view of “business people” makes our industry unattractive to all but the hangers-on in their tribe? I think so. I think that it’s likely.

The screwy art of making exceptions

There’s something I should mention about Stan. Because he’s socially inept and (in his own mind) a tad bit desperate, he fabricates relationships that exist only in his head. His bitterness toward women in general leads him to erroneously up-regulate a woman’s signals. Thinking that women are horrible creatures who are predisposed to despise him, he tends to overreact to basic decency (real and superficial) in them. So he will mistake politeness for niceness, niceness for friendship, and friendship for sexual attraction. Also, his extreme negativity makes him a terrible judge of character. If a woman is basically decent to him, he puts her on a pedestal. She becomes one of those ultra-rare “good ones”, untouched by “feminism” and “frat boys” and the filth of the world. After this happens, she can treat him like dirt and he’ll make excuses for her. He’ll see the light (on her, but not in general) eventually, but his worldview becomes even more depraved as he learns the wrong lesson, that even his “perfect woman” turned out to be awful.

Similar to Stan’s misogyny, software engineers also harbor a generalized dislike for “business people”, whom we tend to view as stupid, emotional, childish, petty, and short-sighted. And about the business people who run our industry, we’re not wrong. We’re just failing to see the whole set of them. (See a pattern, here?) This bitterness doesn’t make us keen observers or tough judges of character. It makes us fucking marks. A naive engineer, whose model of a slimy businessman is a 40-year-old Harvard graduate in a suit, is underprepared when the 25-year-old Stanford “bro”, in jeans and sandals, cuts him out of the startup he built.

In relationships and business, deeply bitter people are often clingy. Whether it’s “women” or “business”, there is some Other that they despise but also depend on, and they tend to caricature it in the most vicious way. Anyone sending signals that negate this stereotype can break through the “bitter shield”, win undeserved trust, and eventually have license to treat a person badly while that person makes excuses for the awful behavior. In dating, the Stans of the world fall for “quirky” girls who’ve put on glasses to send “I’m not a slut” signals without improving their moral character. In business, the bitter engineers fall head-over-heels for talentless young things who read enough Hacker News to know that professing fandom for Postgres and OCaml will make them seem technical and smart (even while they continue to force their engineers to use PHP and work 18-hour days). In all of this confusion, we get cloudy but stable result where most of the clueless young engineers, even if they despise “managers” and “executives” in the abstract, like their supervisors. This is analogous to the common American attitude toward elected officials, and why there is so much incumbency that bad politicians are almost never voted out. Most Americans dislike “politicians” who make backhanded deals “in Washington”, but they love their politicians. “George Starr fixed the pothole on my street!” Well, yeah, that’s what he’s fucking supposed to do (maybe not directly, but you get the idea). These people fail to recognize that their own charismatic local favorites, more often than not, are part of what’s wrong with “politicians”. They also tend, because they’ve put a specific person (the “alpha male” to whom they’ve clung for protection) on a pedestal, to react with undue emotion (a sense of “betrayal”) when the relationship goes sour.

Good and bad tribalism

The truth about us, as software engineers, is that we get our tribalism completely-the-fuck wrong. We can be immensely tribal about stupid shit. If a person doesn’t have an active Github profile, we “flip the switch” (bozo bit) and assume that he’s an idiot, even if he has a completely different job. People who don’t “look like” programmers (and there shouldn’t fucking be a “look”, because technology is too fucking important to push talent out for stupid reasons) face an uphill battle at getting basic respect. We’re quite superficial, and I’ve been guilty of this in the past, too, such as by overvaluing technical preferences as an index of value or intelligence (e.g. “he’s a Java developer, he must be an idiot.”) Our superficiality, however, makes us really easy to confuse and hack.

We tend to think of “non-technical people”, in the business world, as idiots. It doesn’t help fight this stereotype that many of them are idiots, especially in technology, due to the Damaso Effect (which, as I’ve indicated, might be partly our fault).

Before going further, let me give a working definition of idiot for the business world: an idiot is either (a) a person doing an important job poorly, or (b) one doing an unimportant (or counterproductive) job aggressively enough to cause problems. There are many causes for idiocy, and while the cerebral narcissists among us tend to jump to a lack of innate intelligence, that’s actually one of the less common ones. Other issues are (and these will overlap) willful ignorance, lack of care, poor interpersonal skills, dislike of one’s job, and many external ones such as inept (or malevolent) supervision, bad strategic leadership, or environmental incoherency. Over 90% of non-technical people (and probably, to be honest, more than 70% of programmers) are idiots at work and a lack of innate intelligence isn’t the problem. We err when we assume that it is. Our adversaries (who are not always idiots themselves, but who spread and encourage idiocy for their own benefit) can, usually, flash enough cognitive muscle to break our stereotype of “the business idiot” and get us to take them seriously– to our detriment.

For all our superficial tribalism, software engineers are shockingly quick to sell their colleagues out to management, and to do exactly what their bosses want. Let’s use stack ranking as an example. When a company puts forced ranking in place, every savvy manager will hire an “insurance incompetent” or two, and put them on inconsequential work. It’s not a good thing for the company or the world, but it’s a way to put the team at ease because their jobs aren’t at risk; when the stack-rank gods demand human sacrifice, the insurance incompetents go while everyone capable stays employed. This allows members of the core team to focus on their jobs rather than politics. Typical software engineers are too clueless to realize the value in this and, further yet, will vehemently oppose it. “I can’t believe I’m working at the same company as a guy who mixes tabs and spaces!” (“I can’t believe someone else’s money is being used to hire an incompetent and protect my job!”) Many engineers (without political benefit in doing so) turn on their own weak, and will sell out their entire teams if given time in the executive sun. This is because they’re easy to confuse by invoking superficial tribal color. “Don’t worry, Tom’s not an asshole manager. He plays video games and used to code, ten years ago. He’s one of us.” Because engineers are a low-status tribe in the business world, it only takes a few flashes of tribal empathy, from The Business, to compromise the weakest of us. Instead of falling for this nonsense, we need to stop judging people based on tribal identity and start judging them based on what they actually do.

Perhaps it’s counter-intuitive, but managers don’t really suffer from engineers’ tribal dislike of them. We still need people with at least some of these skills. The tribalism makes engineers easy to manipulate. Here’s one place where the two cases (of Stan’s misogyny, and engineers’ dislike of business people) depart. Misogyny actually hurts women. Our dislike of “slimy suit-wearing businessmen” just makes us easier to hack by slimy businessmen who don’t wear suits– because they’re 23-year-old Stanford grads. Businesspeople don’t give a shit whether we like or hate or love or despise “businesspeople”; they just care about making money off of us. And while we should be gladly helping the best of them make money (so long as they don’t harm in the world in doing so, and they share the wealth with us) we should not be allowing them to drive us into subordination.

The right kind of tribalism

The current software tribalism is mean-spirited, exclusionary, and privileged, but it’s also ineffective at getting us what we actually want. For an analogue, peruse Quinn Norton’s notion of white privilege as, in reality, a ruse that convinces disaffected whites to oppose their own economic interests; because, at least, they have it better than the blacks. We’ve created a culture of subordinate and pointless privilege. In software, we now have a world in which well-educated, white men never have to grow up, and this suits the venture capitalists and “founders” because, so long as we aren’t required to turn into adults, we won’t expect to be paid or treated like adults.

I’ve written at length about the value of having a professional guild or collective bargaining. Respectfully negotiating on our behalf, toward our genuine shared interests, will get us a lot further than tribal shit flinging. Rather than having this unfocused dislike toward a large set of people whose skills we barely understand, we should figure out how, with focus and respect, to reach equality. We need them and they need us.

It’s going to be hard to reach common ground with the business elites. There’s much in the business world that is archaic, anti-meritocratic, classist, anti-feminist, irrational, mean-spirited, status-driven, imperialistic, and just plain broken. A world in which “pedigree” and connections matter so much more than substance, drive, and talent is a hard one to respect, and that’s what the business mainstream, at the highest levels, is. (It’s less that way amid the small, local businesses that tech companies, more often than not, blow away.) But what world are we creating, and have we created? The noxious miasma in VC-funded Silicon Valley is not superior to the corporate mainstream “establishment”; it is the establishment. So maybe it’s time to just forget about “worlds” and start talking to individuals as we figure out how to do things better. We had our chance to build a better world, in Northern California, back when housing was cheap and the air was fresh and the word “traffic” referred to telecommunications rather than automotive congestion, and we fucking blew it. Maybe those people in Washington and New York (“the paper belt”) were worth listening to, after all. Maybe people who’ve spent as much time amid bureaucracy and human politics and finance have a thing or few they can teach us.

There are certain tribal values among us, as technologists, that are worth preserving. What makes us unusual is that our discipline is progressive in nature. Code, well written, can be used forever. While most of the world is mired in zero-sum power struggles and territorial squabbling, we get a chance to add, even if in a small way, to the sum of human knowledge. That’s pretty damn cool, and the best things about us as a culture, I believe, derive from the progressive and collaborative nature of what we do. At least on paper, we create new wealth. We solve new problems, and the nature of code is that a solution once devised can be used anywhere.

Unfortunately, there are facts that break against us: our leadership is absolutely excremental, as Valleywag gleefully (and very competently) shows the world on a regular basis. “We” (meaning the executives injected into companies where we do most of the actual fucking work) destroyed San Francisco, and now the world is bracing for our “disruption”, just hoping that a 2000-style dot-bomb crash will prevent us “techies” (meaning the slimy proto-executives whom many of us blindly follow) from ruining everything. We have to fix “ourselves”, and fast. We have to organize so we can choose better leaders. Instead of having puppet leaders shoved into our top ranks from the refuse of the business world, we have to prove to ourselves (and to them) that we can do better when we select leaders who respect the best of our values, while diverting us away from our worst tendencies. They don’t have to be full-time coders. They probably won’t be. They have to be technologists in ethics; being so in craft is important, but secondary.

Right now, as a tribe, we’re far from self-sufficient. Indeed, in the 21st century, self-sufficiency doesn’t really exist. That ship sailed (or, more accurately, that container carrier motored away) a long time ago, and the global economy is far too interconnected. There’s a lot of knowledge that we, as a tribe of a couple million people with elite technical skills, just don’t have. We should be meeting with union organizers in order to learn the diverse forms of collective bargaining, and in order to find an arrangement that prevents the negatives (wage normalization, tyranny of seniority, mediocrity) associated with unions from setting in. We should be venturing deeper into “the business world” to find better (and, most likely, more experienced and older) leadership. There’s a whole slew of successes and failures that the rest of the business and governmental world has seen over the past few centuries, and throwing that knowledge out because we think we’re above “paper belt” politics (and we’re obviously not) does no good to anyone. We’ve got to do two things. First, we have to end our own tribal bigotry and reach out. We must vehemently oppose assaults (external and internal) on our values; but, at the same time, welcome other kinds of people. It’s not just our game, and they know how to do things (such as lead and build organizations) that we haven’t learned to do for ourselves. Second, we need to develop the ability to manage our own affairs. We have to step up, from the inside, and lead. If we don’t, then we’ll continue to answer to the mainstream business culture’s fail-outs, and stack ranking will never go away.

The core of the problem

It’s going to be hard to fix our affairs. To illustrate this, let’s take note of Stan and his dating woes. The transactional, superficial view of dating is that people match up based on attractiveness, whether superficial and physical or total and holistic: 10’s pair up with 10’s, 3’s pair up with 3’s, and so on, and it’s rare that a person gets to go into a higher “league”. Some people find this reductive and offensive, but there’s no question that the early stages of dating often are that way. Of course, as the Stans of the world will endlessly complain, there are skewing factors. Age is one, because men tend to prefer younger women and women prefer older men. Thus, 25-year-old men will readily date 20-year-old women, but the reverse is uncommon. Among college students, a male “7” is unlikely to find a female “7” in his age group, because the women have more options and some are “taken off the market” by older men. He’ll have to settle for a “4” or “5” if he wants relational market equality. Among 40-year-olds, it’s the reverse; average-looking men, in that pool, become highly desirable. Most men who fall into the Misogyny Loop do so in high school or college, when they get shafted by age-skew and there really is a shortage of available decent women (relative to the number of decent men) in the same-age dating pool. It’s not that available decent women (at any age) don’t exist. There are a lot of them, but (among 20-year-olds) they are popped off the market faster than men.

I don’t care to analyze dating, because I’m a 31-year-old married man who believes (and hopes) he is done with that nonsense, for life. It should be obvious that I intend to apply this to business. Business has “marriage/matching problems” and skew issues as people with separate skill sets try to size each other up and find parity. What should the equity split be, say, between two Technology 7’s and a Business 8? How should decisions be reached, and salaries be computed?

Let’s talk about new business formation (startups). The only reason why software engineers are decently well-paid, compared to the rest of the U.S. increasingly-former middle class, is that (at least, in theory) we have an alternative: to do a startup. A good software engineer typically makes $140,000 per year in San Francisco, $110,000 in Chicago, $90,000 in London, and $60,000 in Paris or Madrid. Why? It’s not just cost of living: London’s more expensive than San Francisco, and Paris isn’t cheap either. It’s about competing alternatives. The Googles have to compete with the Facebooks and the Facebooks have to compete with companies that don’t exist yet; and, for all the Valley’s flaws, it’s still the easiest place in the world to raise venture capital. To start a business that is interesting in the technology space, two things (the “2 C’s”) matter: Code or Contacts. If someone’s not packing one or the other (or, very rarely, both) then you can’t afford to make that person a founder.

You’ll soon need accountants, attorneys, HR experts, economists, and sales managers. I don’t mean to denigrate those skills. They just don’t need to be baked in to a new company’s formation. They’ll typically be employees, not founders. You can start with a service like TriNet and “bootstrap” up to a full-fledged HR department, just as you can start with Amazon Web Services (“the cloud”) and build your own data centers later. Early on, however, you absolutely need Code and, even more desperately, you need Contacts. These two assets almost never occur in the same person (they both take years of full-time effort to build, except for the very wealthy are born into Contacts) so they’re often described as separate roles: the technology co-founder(s) and business co-founder(s). In order to have a healthy company without warring tribes, you need equality between the partners. So, at what point are they socially equal, in terms of leverage?

Of course, there’s a hell of a lot of skew. Is a Tech 8, like me, going to pair up with a Biz 8? Not a chance. The market value of a Tech 8 isn’t that much higher than that of a Tech 5. A Tech 5’s salary will be between $90,000 and $150,000 per year; the Tech 8 is at $120,000 to $200,000, depending on location. A Biz 8 can get a $500,000-per-year job out of a 5-minute phone call. They, to put it simply, have more options. Tech 10s have to stay in tech for their skills to be treated as meaningful. (I’d argue that a legit Technology 10 could kill it, with proper training, in business or law or medicine… but I won’t get into that here.) Business 10s can go anywhere in the global economy. There are two fundamental commodities in an economy: Past (property, reputation, connections, wealth) and Future (motivation, creativity, talent, grit) and the exchange rate between the two has always favored Past.

Even in the contemporary technology “startup” world, it matters more to have Contacts than Code. A Tech 8 can write a scalable, back-end recommendation engine in Haskell. She’s incredibly valuable. You can bet a company on her. On the other hand, a Biz 6 can get a TED invite and a Biz 8 can get into Davos. Even a Biz 7 can deliver Sequoia or Y Combinator in an afternoon with half an idea scribbled on a napkin, and can get a total pile of crap “acqui-hired” for $5 million per head by Google. The Biz 8 and Tech 8 “deserve” to be equal in social standing, but they’re not. The skew is enormous. It sucks and it’s frustrating, but it’s something we have to deal with.

If I (a Tech 8 without special connections) went to New York or San Francisco today and looked for a “business co-founder”, I’d have to sift through hundreds of Biz 3-5 who “just need a programmer”, offering 5% equity in companies around their lame ideas, not shared ideas that might emerge and be better than either of us would come up with individually. It’s a dreadful market. The exchange rate between Code and Contacts is morally unacceptable. Contacts is winning so handily that it’s creating tribal hatred and bad startups. It’s driving us, as programmers, toward defensive rejection. We loathe our (objectively unfair) low status relative to the business mainstream, and our loss of the world (Silicon Valley) we created. We should loathe it. We should be disgusted (even though a large part of it is our fault). Unfortunately, many of us overreact. Instead of hating arrogant individuals who lord their unreasonable, unjustified high status over us, we let it evolve into a generalized hatred of “business people” or “suits” or “MBAs”. I’ve been as guilty of this, in the past, as anyone, but we’ve got to fucking stop.

So why is it like this? Why is there so much skew? Part of it is that, sadly, society just has more options for Contacts than for Code. Jeff Dean (a Tech 10) would likely be an obscure programmer without Google. The proving ground of a large corporation that allowed him to hone and show his exceptional engineering ability; without his work at Google, we wouldn’t know that he’s a Tech 10. On the other hand, Biz 10’s aren’t anywhere near tech companies; they’re managers of billion-dollar hedge funds who turn away almost all investment offered to them. Hell, it’s rare that you find a Biz 6 willing to be a “business co-founder”. A Silicon Valley founder is a middling product manager, and the true executives are the investors, and savvy people spot the pattern quickly and head for the investor ranks if they’re going to be part of that game. Biz 5-6 are routinely offered entry-level (associate) positions at prestigious venture capital firms, and Biz 7-8 get partner-level jobs, offered on the spot. Yes, it’s unfair as hell. So, what are we going to do about it?

I’m coming to an answer that isn’t the forceful kind of solution that I tend to like. Slinging mud is a hell of a lot of fun. I won’t deny that. And there’s a world of deserving targets out there. However, is hating “The Business” getting us anywhere? Or might we do better to swallow our pride, and to replace unfocused tribal dislike with focused and deliberate organization around our own interests? I think the answers are obvious, here.

If we don’t want for the bulk of us to answer to Biz 3’s for the rest of our lives, then we need to start attracting the Biz 7-9’s who have other options. We have to convince them that what we can build is genuinely important (which means we need to stop it with the played-out social media nonsense). They don’t need us, but we (probably) need them. Their skills, we can learn and grow internally, and we’ll have to do some of that. Their contacts, at least for now, have to be drawn in from outside, since we (as engineers) are a deeply middle-class group. It’s going to be hard to do this. It’s going to be especially hard to convince them to form partnerships at the level of equality that we deserve. I don’t have all of the answers, certainly not yet. I do think that we’d have better odds if we took stock of, and reformed, our attitudes toward business people and what they do. This will also force us to acquire a sense of nuance that will enable us to push the actually scummy business leaders (who are, right now, most of them) out of our industry. It can’t hurt.

It might be time for software engineers, especially in Silicon Valley, to unionize.

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’ salaries 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.

Are Haskell engineers second-rate? (Answer: no.)

Before I risk offending anyone with my provocative title, I’ll give away the answer: it’s “no”. However, there’s an interesting discussion to be made of this. Not to pick on Haskell or Erlang or Clojure in particular, Piaw Na made this comment in this Quora answer.

A fixation on programming languages is the sign of a 2nd rate engineer/computer scientist.


Even when I was hiring to fill an Erlang server position, I found that the Erlang specialists were much worse engineers than hiring a great all-rounder and having him learn Erlang (or whatever) to fill the position.

Na’s argument is similar to the attitude that is in vogue in technology companies founded in the 1990s, such as Google and Amazon. At the time, programming language research was considered to be a dead and probably useless field. Large applications were written in C++ and possibly Java. Python, ten to twenty years ago, was considered cutting-edge and risky, and languages like Lisp or Haskell were hardly used at all. Paul Graham deserves a lot of credit, not just for the decision to use Lisp for his startup, but for his eloquent defense of it and expressive languages (like Python) in general. From his essay, “The Python Paradox” (all emphasis mine):

In a recent talk I said something that upset a lot of people: that you could get smarter programmers to work on a Python project than you could to work on a Java project.

I didn’t mean by this that Java programmers are dumb. I meant that Python programmers are smart. It’s a lot of work to learn a new programming language. And people don’t learn Python because it will get them a job; they learn it because they genuinely like to program and aren’t satisfied with the languages they already know.

Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I’ll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they’ll be able to hire better programmers, because they’ll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don’t learn merely to get a job.

These passages don’t necessarily contradict each other, but they suggest different hiring strategies. Piaw Na would suggest that you should be more leery of people who identify strongly as Clojure or Haskell engineers, while Paul Graham suggests that you want programmers who hold strong enough opinions about languages to invest themselves heavily in the more obscure ones.

So who’s right? Obviously, they both are to some degree; otherwise, this wouldn’t be an interesting essay.

Programming languages are important to great software engineers. There’s a “languages don’t matter” attitude among managers and “architects” in many software companies, held by people who haven’t written a line of code since Macarena came out. People who actually still write code care immensely about their tools. All that said, Piaw Na is correct on the tendency of monoglot programmers toward mediocrity. Great engineers want to use the right tools for each job, and programming languages are an area where there isn’t one right tool for every job (far from it!)

Whether it’s Java or an arguably superior language like Haskell or Erlang, a programmer who refuses to learn things that are outside of his comfort zone is likely to be a mediocre one. While any programming task can technically be achieved in any language (Turing completeness) they vary rapidly in practical capability, and there really isn’t a single language that dominates the others, because programming is diverse. Some algorithms are nearly impossible to write efficiently without manual memory control, which necessitates using a language like C. For a typical production server that should never fail, Haskell is probably the strongest choice. For interactive exploration, Clojure’s first-class “repl” (interactive console) is hard to beat.

I’ve bashed Java a fair amount (perhaps unfairly) and that’s because I absolutely loathe the “Java Shop” culture. Giant XML files, AbstractFactoryManagerSingletonFactory patterns, IDE-dependent builds… all that nonsense can go fucking die in a taint fire. The lack of taste in the corporate Java culture is astonishing. It generates ugly code with no personality and that falls apart rapidly because no decent engineer wants to maintain it. The monoglot nature of the corporate Java community is, quite likely, correlated to these cultural problems. When you have incurious developers, short-sighted and clueless management, and a language that basically works as long as you throw enough engineers at the problem, you’re simply not going to stumble upon a reason to use anything other than Java.

The noticeable trait of mediocre Java developers (and it’s probably similar for .NET, and maybe even C++) is that their conception of programming is limited to what can be done in Java. Their bosses won’t let them use other languages, so why learn anything but Java? Ask one of them how an assembler or an operating system works and you’ll get a blank stare. Ask about machine learning or computer graphics and you’ll hear grumbling about how linear algebra was taught at 8:00 am. They’ve forgotten how to write programs and haven’t run one since college; they just make classes all day, and it becomes the job of “some smart guy” (the same “some smart guy” who gets you productive again if “your Java”, meaning your IDE, breaks) to staple them together and throw something into production. The corporate programmer culture has dumbed software engineering down to this, and the result is that CommodityJavaDrones haven’t been near actual computer science in years, even if they’re up to speed on how to write “user stories” and groom “back logs” and play politics.

It’s not Java’s fault. The language has its warts, but business-driven stupidity didn’t come into being in 1995 and it would have glomped on to something else if Java hadn’t come along. James Gosling didn’t intend AbstractFactoryVibratorSingletons when he invented the language. He needed a fairly low-level language (like C) for the JVM. For the problem he was trying to solve, Java worked well.

Comfort zones are for losers

Piaw Na’s right that not all programmers in the more interesting languages (e.g. Erlang, Haskell) are first-rate. Bad code and sloppy engineering can be found in all languages. Sometimes, a neophyte will have the luck of landing in a first job using a more expressive language, but still fail to grow. It’s rare, but I’ve seen it happen.

This is an industry in which anyone who wants to be decent can’t afford to have comfort zones. If you cop an attitude of, “I’ll never use a statically typed language” or “I just don’t do low-level” or “I stay away from the browser because Javascript is ugly” or “I’ll never understand operating systems” then you’re probably not going to become a first-rate programmer. It’s paradoxical and difficult, because you have to be very selective in what you work on to keep learning and stay sharp, but you can’t rule out whole areas of computer science, either. (You can rule out process bullshit like “story points”; that will just rot your brain.)

If you’re a curious person, you’re not going to ignore a whole area of computer science just because it’s difficult. Things change too often. Obviously, it’s fine (and expected) to have preferences. It’s setting up brick walls that I have an issue with. Of course, we all create brick walls by necessity when we’re starting out and we need to be selective in what to focus on (lest we get a mediocre knowledge of many things). I’d just argue that the better computer scientists are the ones willing to break those walls down when there’s a good reason to do so. If you’re doing computer science right, then every problem should be new and they should tend to progress in reward, complexity, and challenge. The solved, repetitive stuff should be automated when possible.

Paul Graham warns about the danger of using a language as a comfort zone by introducing the concept of “Blub”. Blub is a stereotypical mediocre language that a monoglot, corporate programmer uses as his model for all forms of programming. The Blub programmer sees lower-level languages as braindead, and higher-level languages as abstract and just plain weird. Blub is, of course, not a specific language but an artifact of an attitude. Java, at least of the enterprise variety, is probably the Blubbiest of Blubs, but there’s nothing that stops a person from taking Haskell as his own personal Blub.

So what makes Java such a common Blub? Part of it, I think, is that the language does many things well-enough. If you are going to be a one-language programmer (or, worse, a one-language company, a “$LANG Shop”) then Java isn’t such a bad choice. It’s not hard to learn, it’s possible to write performant code, and the library support is strong. Let’s look at the standpoint of a middling engineer, because good engineers are almost certainly going to be polyglot, and crappy ones don’t care about languages or software engineering. This middling vantage point is also useful because in business-driven engineering shops, middling engineers tend to be the ones emerging as leaders. A middling Python engineer is going to realize, quickly, that some routines need to be written in C, because Python generally isn’t fast. (Crappy engineers don’t think or care about performance. It’s just mathy voodoo to them.) He might not be proficient in C or enjoy using it, but he’s not going to write the language off. The middling Java engineer will never need to know what C even is.

As far as Blubs go, one could do worse (on language fundamentals) than Java. It’s not PHP or Javascript or Visual Basic. Culturally, however, it tends to be a toxic Blub. Na points out that someone who refuses to code outside of Erlang is probably not a first-rate developer. Fair. I’m a huge fan of Haskell and would probably pick it for most projects if I called the shots, but I’ve also exposed myself to Clojure, C, Python (for the data science libraries) and Scala. I certainly think that comfort zones are a sign of a second-rate programmer. Even still, the CommodityJavaDrones are often third-rate. What’s more pathetic than holding fast to one’s own comfort zone? Living inside someone else’s.

Business-driven engineering (or: waterfalls of sewage)

For an aside, one of the reasons why first-rate engineers don’t seem as adamant about programming languages is that, often, they have the credibility to make technical decisions. (If they don’t, they’re in a company that doesn’t recognize talent, and should leave.) If you’re junior and powerless, you care a great deal about whether you wind up at a “Java shop” or a “Python shop”, because you’re not going to be allowed to use anything but the house language. If you’re senior and have clout, you tend to work on new projects and get to choose the tools. Great engineers avoid business-driven engineering and closed allocation, at any rate. Of course, no one is born as a first-rate engineer, so in our “good, working toward great” years, we do have to pick companies based on those sorts of signals. If a company’s a Java shop, it sends a really bad signal.

Java isn’t my favorite language, and I don’t have much use for the (false) claim that languages don’t matter, but it is the right language for some problems. If you have to be on the JVM, and can’t afford the (small, but nonzero) overhead of Clojure or Scala, then Java’s the right choice. As I’ve said, the ugliness of Java isn’t all intrinsic to the language, but has a lot to do with the anti-intellectual culture of corporate Java.

For those who’ve been lucky enough to avoid the hideousness of most programming jobs, here’s how many software companies work: business comes up with the ideas and defines the work, product managers intermediate and sit in on interminable meetings, and programmers just implement. Most “scrum teams” are just ticket shops. The engineer has no autonomy. This is business-driven engineering. I’d call it “waterfall of sewage engineering”, but decrying a “waterfall” makes it sound like I support much of what is called “agile”, and I don’t. The problem with “agile” is that it’s still closed-allocation, business-driven engineering, meaning that nothing was accomplished. Trying to “fix” business-driven engineering is like putting salt on a turd to make it edible: it just doesn’t work that way.

This may be paradoxical, but when you have an engineer-driven firm, you get better engineering and better business. See, business-driven engineering rots the mind, because it takes what should be a creative and challenging discipline and turns it into “Write me seven classes and 17+i story points by Friday.” It’s also part of why there’s an age-discrimination problem in technology; if you spend your 20s doing that crap, you actually will be a corporate executive (as in premature dementia; not necessarily as in rank and salary, unfortunately) by age 30.

Are there excellent engineers who happen to use Java? Absolutely. Are there not-great programmers in the Haskell community? Sure. If you really want to encounter that underclass of non-programming programmers, though, you have to descend into the shit-lava inferno of business-driven engineering.

As for bets and things…

Hiring is, to a very large extent, about making the bets with the best odds. Does using Haskell guarantee that you’re going to have excellent programmers? No. And Piaw Na is right that talented programmers unexposed to it shouldn’t be written off in hiring, because great engineers can learn new languages quickly. (It takes longer to learn an average corporate Java codebase, those being verbose and generally of low quality, than to learn Haskell or Clojure.) Do the odds favor using languages like Haskell and Clojure, if you want to get mostly wheat in your hiring process? Absolutely. Not only do you get (on average) better developers in those languages, but you’re also going to be in access to stronger communities.

I’ll say this, too, for most Haskell and Clojure engineers that I know: most of them aren’t monoglots who stick to their comfort zones. At a conference or talk dedicated these more “elite” languages, there are plenty of presentations that bring in ideas from other languages and paradigms, whether it’s logical programming or assembly hacking. What makes these languages and communities different and somewhat special isn’t that there are no mediocre engineers, but that the average engineer is quite strong. That creates an energy, and a sense of friendly competition, that you just don’t see in an enterprise Java shop.

The Python Paradox doesn’t guarantee great hires all the time. That requires, well, great hiring. But I think it’s pretty obvious, on the “do languages matter?” debate, which side the odds favor.