Monthly Archives: October 2014

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.

Tech hiring, poker, and (not) playing to win.

If you’ve been around this industry for long enough, you’ve heard plenty of hiring managers complain about the difficulty of attracting and keeping good people. Often, you hear excuses that bear no resemblance to reality, like “There just aren’t any good people out there” (not true) or “Talented people just don’t want to live in the Midwest” (not true, and goddamn insulting to the Midwest). When you hear those sorts of things, you’re dealing with a losing player who doesn’t know why he’s losing. Sadly, that’s the more common case. It’s downright refreshing to hear a middle manager admit something like, “We can’t get talent because upper management doesn’t want to pay for it, and because we’re solving a stupid problem, and because we’ve fucked up our reputation with the past 5 years’ worth of short-term thinking”, but it’s not terribly common.

Winning pots vs. winning money

I’m going to use poker as a metaphor for hiring. The connection’s probably not obvious yet. The reason that it’s interesting to me is because gambling is an activity at which bad players (a) can think that they’re winning if they aren’t keeping track, and (b) usually have no insight into what they’re doing wrong. With poker, a common mistake of inept players is to focus on winning pots instead of money. Skilled and unskilled players, over time, get the same number of good and bad hands as anyone else, and the inept players tend to win slightly more (!) than their fair share of pots. They lose money, however, because not all pots are equal in value. If you play too many hands, you’ll win more of the small pots but lose your shirt on the larger ones.

The dopamine-fueled thrill of bluffing with a bad hand is powerful, but hands that can be won so easily are rarely worth much. The high-impact rounds of poker are the ones where multiple players have strong hands, and see it through to showdown, and not the ones where you can bluff the rest  of the table out of the game. Good players focus on the big pots. (For an aside: good players will bluff on occasion, but it’s not to win the free pots, which are of low value. You bluff so that, when you do get a killer hand, others will play against you. If you never bluff, others will fold when you play aggressively, and you won’t make as much money.) Good players don’t set a goal of winning as often as they can, because that’s a fool’s game. They aim to maximize how much they win on good hands, and minimize their losses on the bad ones.

Hiring

What does the above have to do with hiring? Well, let’s look at just one of the cultural negatives of Silicon Valley: ageism. Why might such a prejudice be there? The answer is that most hiring managers are playing to win pots, not to win money.

The ageism and the low status of software engineers exist because most tech companies’ managers are running a pot-winning strategy. Let’s say that a 1.2-level programmer has a market salary of $100,000 per year and is worth $150,000 to the business; at the 1.8 level, we have a market salary of $150,000 and a business value of $500,000. (Are those numbers accurate? It depends on the problem. For a typical tech company, they’re about right.) From that, there’s seven times as much true profit in hiring the 1.8 programmer. Doesn’t this predict the opposite of age discrimination? From those numbers, you’d expect employers to be chasing the experienced engineers, not shunning them. That’s what would happen if these guys were playing to win money, and not pots. So why doesn’t that happen?

The common explanation given for this is a sociological one. Companies need a few 1.5 engineers, and possibly a 2.0 chief architect, but they don’t need many of them. That’s why, many argue, it’s hard for experienced and capable older engineers to find jobs. (For the incapable older engineers… forget it. Time to become a partner in a VC firm.) This explanation is a cop-out. If you can’t hire talented people, then you need a pyramidal structure and infantilizing policies. However, the success of Valve’s open allocation shows that one can build a company entirely out of high-quality people. You just need progressive management if you want to keep it that way. It’s a vicious cycle. If you structure your workplace as a pyramid, you’ll have a lot of untalented people at the bottom, and therefore need to keep the hierarchy in place.

The real explanation for this phenomenon is that hiring managers are just bad at this poker game. First of all, they’re playing for a high frequency of wins, and not for the big wins. If you tailor your hiring strategy toward mediocrity, you’re going to have a lot of catches, but they’re going to be of the “spend $100,000 to make $150,000″ variety. This actually doesn’t scale well, at all because it loads the company up with inexperienced or mediocre engineers. There are plenty of nonlinearities in software engineer hiring and building a large team is, if it can be avoided, undesirable (see: Brooks’s Law). Second, they mark their successes not based on the true profit (the difference between an engineer’s value-add and the cost of hiring her) but based on the profit relative to the market rate. It’s actually a $360,000 win to hire a 1.8 engineer at $140,000– at least, if you staff her on 1.8-level work– but HR marks it down as a measly $10,000 gain, because that’s the difference between the accepted salary and the market level of $150,000.

Hiring managers operate as if they’re trying to maximize the bulk number of wins itself. The going strategy, then, is to target the young, because they are the most likely to under-value themselves by large margins. A 30-year-old who is any good, knows it. A 23-year-old on an H1-B visa has no idea where he stands relative to other programmers. You can probably get him to agree to a salary that’s $30,000 per year below market. From an HR perspective, that seems like a massive victory. Really, it’s not. Compared to the gain in hiring a more experienced programmer, even at market salary, that $30,000 is a rounding error.

“Toxic wins”

Gambling and business both have a pattern that I call the toxic win. That’s when a bad strategy delivers wins that “feel good”. Subjectively, it feels like like it’s working, because of peoples’ optimistic memory biases. Even most gamblers don’t keep good track of their wins and losses and, in business, it’s nearly impossible even to measure (in the short term) wins and losses at all.

To use poker for an example, a toxic win would occur where an inept player aggressively bluffs, wins a small pot uncontested, and congratulates himself. What he learned: bluffing aggressively makes you win more often. What he should have learned: the other players had weak hands. Aggressive bluffing into a hand when others have strong hands is a quick way to lose a lot of money in the hands that actually matter.

In hiring, the toxic win is when a talented young programmer sells himself egregiously short. Coming out of college, he values himself relative to his peer group (0.9 to 1.2) when he’s actually a 1.4. It doesn’t happen often, but once a hiring manager gets that kind of win, it becomes expected. It’s like the “short commute bias” that explains chronic lateness. In many cases, it’s not that chronically late people are inconsiderate, but that they suffer from an optimistic memory bias: based on that one time that the road was absolutely clear, that they could drive 80 miles an hour, and they got to work in 20 minutes (in a commute that typically takes 30) they’ve begun planning as if the actual time-cost of the commute is 20 minutes. This means that they’re typically late, and usually have excuses (bad traffic, poor weather, misbehaving pets or kids) for being so because, goddamn it, that commute should only take 20 minutes. In short, a rarity is presumed to be a permanent entitlement, and suboptimal decisions result.

You see the short commute bias all over the place in business. It explains why managers (and engineers) systematically underestimate how long it takes to complete a project, but you also see it in HR. As soon as That One Kid takes a $25,000 drop relative to an appropriate salary (never mind that he left, one year later) hiring managers take that to be the new appropriate salary for that level. When they struggle to fill the position, trying to replicate that rare toxic win rather than building a business, they bitch about “inflated salaries” and a “talent shortage”.

Mixed messages…?

It’s subtle, but I’ve actually argued two cases that seem to contradict each other. My first complaint is that hiring managers over-focus on a high frequency of mediocre wins, to the detriment of experienced software engineers, and fill their companies with inexperienced or mediocre people that they often don’t know what to do with. This accuses them of over-hiring. My second complaint is that they suffer from “short commute bias” and that they therefore miss opportunities to hire, because they’re holding out for that rock star who severely underprices himself. This accuses them of under-hiring. Oddly enough, both are true. (Generally, it’s not the same people who are under-hiring and over-hiring.) But why is this? What would impel people toward two opposing kinds of incompetent play?

Oblique arbitrage and social status

If you’re an economist, you might view wage-setting and talent standards in such terms and expect software companies to staff themselves with the (seriously underpriced) more senior engineers. This assumes that companies are rational actors. But companies don’t “act” at all; people within them do. As it turns out, people are more sensitive to social status than quantifiable economic gain.

We can’t measure social status precisely, but we can estimate it. Every corporation conceives of itself as a meritocracy; there’s no company that cites “Nepotism, Mediocrity, and Chicanery” in its “core values” statement. Job title, salary, autonomy, and reporting structure are all forms of social status that, at least in theory, the company attempts to correlate with a person’s capability. Often, these assessments are way off; but companies tend to converge, at least, in consistency in how they are inaccurate (overpaid people will also be over-titled and given more difficult project, for example). In software, I’ve developed a scale for estimating engineer maturity. It’s not perfect, but it’ll work for our purposes, and I think it reasonably models social status at a typical tech company. An engineer considered to be at the 1.5 to 1.7 level will usually be called a senior software engineer. If the person’s estimated at 1.8 to 2.0, you’ll see a title like staff or principal given. At 2.1 to 2.3, you start to hear terms like fellow. However, titles are, in general, the least interesting variety of social status. More interesting are compensation (which we’ve discussed) and project allocation. If you’re perceived as a 1.5-level engineer, you might expect the company to line you up with 1.5-level work. In practice, most people get work below their level of capability, because companies want to avoid the risk involved in 1.5+ level projects whenever possible. They still want to align the people they consider best with the hardest projects, but usually the desire is to have people working half a point below their actual capability, because employers believe that it minimizes risk.

From day to day in the workplace, people don’t assess their wins and losses in terms of dollars, but in social status. If you get a 1.5-level engineer to accept terms of employment (including, but not restricted to, compensation) appropriate to 1.4, then you’ve made a 0.1-point gain. But if you get him to accept a package appropriate for a 1.2 engineer, that’s a 0.3-point gain. The economics aren’t really considered. That’s three times as much “winning”! A huge win, in this calculus, would be to have CS doctorate from MIT fixing bugs. In terms of social status, it’s a great brag; “I’ve got MIT PhDs sweeping my floors”. In economic terms, it’s pissing away millions in lost opportunity.

Do I mean to suggest that companies, or even managers, are out to deliberately underemploy people? It’s probably not in their interest to do so. After all, if you give a 1.5 engineer the work, autonomy, and conditions appropriate to the 1.2 level, you’re probably not going to collect 1.5-level work. What most companies (and managers) want is excess capacity: a 1.5+ who’s willing to take 1.2-level conditions and do 1.2-level work, but can bring out the bigger guns when needed.

What am I suggesting? Some say that companies are in the business of buying low and selling high. Not so. Often buying high and selling higher is a better move. It’s the difference that matters. People intuitively understand this, and make good choices when the decisions are quantifiable and purely economic; but when shit gets sociological, and the nonlinear transforms come out, they start making terrible decisions. A 0.3-point difference between quality of programmer and work conditions isn’t what you should be optimizing for; social status “points” don’t really matter when you ought to be focus on delivering value to customers and making money. You should be in the money business, not the social status business. If you systematically under-employ and under-reward people, that’s not an arbitrage; you’re probably pissing away millions of dollars in lost opportunity.

Results… ?

One typical corporate-political tactic is to use phony existential risk to argue for what one wants. “Using <outdated technology X> will annoy me and hurt my career” evolves into “We’ll get no talent if we continue with <X>.” This is how we get into the religious wars for which technology is notorious. Because many software engineers are petty, short-sighted, and socially inept, premature escalation to management is commonplace (and that’s one of the reasons why we get no fucking respect). Managers are so used to hearing “we’ll get no talent if we…” that they pretty much ignore that complaint. The problem, of course, is that many of the things that management does (closed allocation, low compensation, micromanagement) are genuinely talent-hostile; but our tendency to present minor differences of opinion as eschatological matters has stripped us of any credibility when we’re actually right. Closed allocation is talent-hostile and does destroy technology companies, but not with immediacy (and, sadly, its tendency toward decline takes long enough that most executives don’t care).

I’ll say one thing: the “we’ll get no talent…” exaggeration is inaccurate, and a tad bit offensive. I’ve worked in some mind-bogglingly shitty companies, with awful health benefits and stupid policies all over the place, and they all managed to have at least a few talented people within them. Those high-talent people may have been systematically underutilized, but they were there. A company that doesn’t offer relocation, skimps on health benefits, or deducts sick leave from an already tight vacation allotment is clearly not playing to win. Or, in the poker analogy, it’s playing for irrelevant small wins while missing high-impact opportunities. That’s awful, and it leads to mediocrity, but the “we’ll get no talent” argument is just empirically wrong.

If you don’t play to win, you still get some talent. The difference is in degree. Do you want to be MIT, or a second-tier state school? The second-tier state schools still have some talent, and their best students would easily fit in at the Harvards and MITs of the world, but the synergistic “energy” that you get when a large number of talented people come together is usually not there. Since organizations are driven by group dynamics rather than talented individuals, a company needs that “energy”… but usually has no idea how to get it.

Of course, it’s quite possible that one’s company doesn’t need or want to be an MIT. There’s a lot of unglamorous work that needs to be done in this world. Even the most wrongheaded, talent-hostile companies can attract smart individuals. That’s not even hard to do, because even smart people need to eat. If you want your organization to lead, however, you’ve got to play to win the game, and stop optimizing for silly, small-ticket micro-victories. The good news (for the progressive executive) is that the technology industry is so badly run, right now, that good leadership is a welcome and extreme rarity. There’s a lot of untaken reward sitting out there for the few that have the courage to come out, show genuine leadership, build talent-friendly companies as opposed to social media cantrips, and actually play to win this game.