There’s a strong resentment that software engineers and technologists have toward “non-technical” people or “business people”. We compare our situations, and our impulse is to find the arrangement unjust. Based on fundamentals, things are a bit off. We technologists work harder, tend to bring more in terms of natural ability, and yet “they” (meaning executives) make three or ten or fifty times as much, for considerably less work, and they have a lot more job and career security. We learn new programming languages and tools (as our jobs, constantly evolving, require) on our own time, and sometimes sacrifice weekends to tackle production issues. They, on the other hand, can work 11-to-4, because their bosses care more about in-group cohesion than what gets done. We get pulled into meetings that we can’t say “no” to. They call those meetings. We live in fear of “Agile” processes being imposed in order to micromanage us. They decide how we are managed, and what we work on. We have little say in how our performance is evaluated. They define their jobs and, unless their assertions are utterly unreasonable, write their own performance reviews, easily justifying raises. We start struggling to get jobs at age 40. They hit their peak in their late 50s. It does seem unfair.

Why are “they” winning? It’s a lesson in collective intelligence. It really matters. We beat them, pound for pound, on individual intelligence– but that doesn’t matter. Often, we use our individual gifts to compete, stupidly, with each other. We need to stop being resentful of “business types”, and start learning from their superior collective intelligence. What are they doing that we aren’t? We’re working harder and we are smarter, individually speaking, but they are working smarter, which is what actually matters.

Look at a typical Harvard or Stanford business school class. Some of the students are brilliant, many are above-average, and some are depressingly mediocre. Perhaps 7 to 10 percent of them have the natural ability to do what a strong programmer can do, and yet almost all of us could do the 6- and 7-figure jobs that they move into. They’re not idiots by any stretch of the imagination, but only a few would be notably sharp by a capable programmer’s standard; some would be our peers, very few would be superior. In spite of this, because they pool resources and connections, they move along to high-status jobs earning $300,000 per year or more, and a number become CEOs earning an order of magnitude more. The ones who become the venture capitalists who run technology are, in fact, the runners-up; they’re the ones who didn’t get into stat-arb funds or private-equity firms or Fortune 500 CEO positions.

I’m not pointing this disparity out for the sake of denigrating anyone. In fact, it should become clear that I intend the opposite: it’s impressive what they’ve achieved as a collective, and we should learn from it. What is it about these people that has them outperforming us, as programmers and technologists, in terms of prestige, economic wealth, and general respect? Can you even imagine a Harvard MBA justifying his own working time in terms of two-week “sprints” or “iterations”? Of course not. It’s inconceivable. So what did they do right that we did wrong?

Rather than getting angry about their superior status and compensation, and our inferior lot, we might do better to observe what these people have done in order to get where they are. It seems to be a lesson in group power and intelligence. Politically speaking, a group of people who protect and assist each other, without question, will always do better than free agents acting alone, no matter how talented the latter group may be.

Like anyone else, I have my bitter moments. With my intelligence as well as the pedigree that would come from, say, Harvard Business School, I’d have an invincible combination. So perhaps I should have done that, instead, during the years that I spent goofing around in startups and tech companies. Had I taken that other route, I’d probably have my own company and be calling shots, instead of spending so much of my career in reaction to others’ suboptimal decisions.

I didn’t, and at 32, it’s probably too late to take that route. (An MBA doesn’t open the same doors when you’re old, and I’m a non-drinker.) When I was the right age for it, I was too idealistic. I spent my mid- and late 20s in a startup, and then Google, and then another startup, because “technology is the future”. That is true, of course. Technology is the future (or, at least, an integral part of it). However, an MBA gives you a future. As for 10 or 20 years in technology… I’m not so sure. With “Agile” and open-plan offices (both designed around the rapid hiring and facile control of cheap, fungible, talentless engineers) becoming the norm, I don’t think that expertise or technical excellence are valued anymore. I’d love to see this change, but it looks like an uphill battle.

To a large degree, though, I’m committed to the technical vision. As lucrative as it could be, were it still an option, I don’t want to be crashing third-world currencies for sport. I want to do something useful and important; that matters more to me than the difference between “comfortable” and “rich”. So, the fact that I’ve “lost” those 7-figure, world-hurting opportunities is hardly something to be upset about. What I don’t want to lose is the battle for the soul of technology.

We’ve let this industry be invaded by the worst kinds of psychopaths. Programming used to be an R&D job; now we have to deal with two-week “sprints” and “user stories” and, worst of all, the sorts of mediocre, mindlessly obedient colleagues who will put up with that nonsense (and for whom such processes are designed). That brings discomfort and humiliation as well as financial mediocrity. Writ large, it also makes us an underperforming industry. Innovation isn’t possible under “Scrum”.

The picture is bleak, but it doesn’t mean that we should abandon technology. It’s fucking important. It’s worth fighting for. What we do, as programmers, isn’t just the production of software. We solve problems. We throw ourselves, day after day, into a kind of work that requires precision of thought (a trait that not many people have developed). That makes us the lifeblood of an advanced economy. The status of our industry, therefore, is worth getting right. We ought to fix it.

The extremity to which we take our tribalism, however, does us no favors. We’ll have to work with people who aren’t like us in order to get anywhere. Don’t get me wrong: the upper ranks of our industry have been invaded by narcissists and psychopaths, and I want to drive every single one of them out. What I don’t like about us is our tendency to downgrade non-technical accomplishments. Our tribal antipathy toward “business people” is one example of this. I’ll admit that I’ve been guilty of this in the past. I’ve said a lot of negative things about “business guys” before but, as I get older, I recognize that there are a lot of intelligent, well-intended people who’ve dedicated their careers to solving business problems instead of programming ones. Pretending that we’re better, just because we can write code, does us no good. It only deprives us of possible allies, because we’ll learn a lot more and get farther if we can work with other people who have the skills we lack. Worse yet are the idiotic sectarian divisions we’ve let form within the programming community: “Agile” versus “enterprise”, tabs versus spaces, Ruby versus Java, women versus “brogrammers”, young versus old, Bay Area versus “the sticks”. We can’t afford this. These divisions make us weak and manipulable. Many of them don’t make any sense. The quarreling turns us into a low-status group of people. Instead, we need to unite around our shared interests.

Why do corporate executives get so much more respect, autonomy, and money than us, despite working significantly less than we do? Because they don’t let people divide them. It’s that simple. They protect each other, and this makes them collectively strong. A graduate of Harvard Business School will place his least favorite classmate in an executive role, for the good of the group; for a contrast, on our side, I still get shit on for stupid things that I said at Google, 5 years hence.

A friend of mine worked at a large bank with “360-degree” performance reviews. Ratings were on a 9-point scale with 5 as the intended average. The lowest-rated group was technology, where the average person got about a 6.5. The salespeople and executives and business analysts all gave each other high ratings, regardless of whether they thought each other “deserved” high scores, and so all of the “soft skills” departments came in with averages above 8.5. The programmers gave each other “honest” ratings, which shows collective stupidity, because it showed a willingness to rat each other out to management. The business people had the collective and political intelligence not to put bad scores, even when they were deserved, on the record. In most of the bank, people wrote reviews for themselves and had them signed by peers. There was a mutually beneficial (i.e. positive-sum) trade of credibility going on. Business people are smart enough to give criticism verbally, off the record, and to give glowing reviews when on the record. They recognize that preserving the credibility of the group is one of the most important things that they can do at work. Not so for programmers.

I can imagine that some programmers will read this and say that it proves that we are the honest ones, and that “business people” are corrupt in some way. I disagree completely with that viewpoint. They played politics effectively, and the programmers didn’t. End of story. The business people (traders, investment bankers, salespeople) saw that the executives were trying to collect data that could be used against them, and so they jammed the signal in order to minimize the probability of harm coming to anyone. The programmers played politics poorly, because they couldn’t keep their mouths shut, and probably got hit harder in the next round of layoffs.

This kind of “honesty”, shown by the programmers, I find to be non-virtuous. While I dislike deception, I also think that many forms of “honesty” are harmful, serving only to cause needless drama and friction. If I find a stranger unattractive, I am going to hide that reaction, because I’m not a jerk. What good would it do, to voice that opinion? None at all. Not all information deserves to be shared and some information should be concealed, even if using half-truths or (on occasion) lies. Likewise, I’m not going to sell out someone I perceive as a low performer unless he’s an existential threat to my career or to the company. If his only crime is to draw a salary of X and furnish work that could be hired at 0.9X, who cares? It’s not “honest” to rat him out to management as a below-average performer; it’s stupid. It would only make a mess.

Programmers are “honest” when it comes to reviewing each others’ performance (which is not to say that they’re correct) and it tends to have three effects. One is that it creates drama. The business people realized that if everyone got top ratings and glowing verbal feedback, the performance-review system could be rendered a formality and they could all get back to work. Problem solved: it becomes a once-a-year annoyance that takes up half an afternoon, rather than something that people fret and grouse about for months beforehand and afterward. The programmers, by being stupid and back-stabby, gave the performance reviews teeth, and created drama that lasted for a long time. The second is that it creates division. Numerical performance scores lead to false objectivity and that leads to permanent rifts within the company, as people withhold information and form alliances in order to game the system. Thirdly, it makes programmers look incompetent. If they’re getting the lowest ratings (because they’re slamming their peers, reports, and bosses) then the organization concludes that must be the worst people in the firm. They’ll never get respect. In the Philippines, this is called the crab mentality: if programmers worked together, they could escape their low professional status (the bucket); however, the constant fighting for slight, typically transient, individual superiorities keeps them all trapped.

Most doctors have peers whom they consider below-average in competence, of course. The same is true with lawyers. It’s also true of business executives, and professors, and everyone else. There’s no professional group in which there aren’t people who consider some of their colleagues to be idiots. Even still, they’ll never say such things about each other, in a context where it could hurt that person’s professional future, except in the case where someone is unethical or dangerous. If you’re seriously ill and have a team of doctors, they might not all like each other, but they’re not going to show it in front of you, the patient. Programmers, unfortunately, don’t have this sense of professional solidarity. They’ll call another programmer a “fucking idiot”, in front of a manager or executive, because they don’t like his indentation style. It’s so easy to turn us against each other, and we all suffer for it.

To continue the example above: on numerical performance scores, it’s obvious to everyone except for the programmers that those don’t exist for the employees’ benefit. (Programmers are too earnest, and actually believe the company when it says that such a management change exists for mutual benefit.) True high performers have no need or use for numerical scores, low performers (or those labelled as low performers) get fired, and the people in the middle get varying degrees of humiliation: being tagged as “good but not promotable” (70th-90th percentile) or “solidly mediocre” (30th-70th percentile) or “probably disposable” (10th-30th percentile). The salespeople and traders and equity analysts at this bank understood, when this numerical peer-review system was rolled out, that a game was being played against them, so they jammed the signal with positive reviews exchanged for other positive reviews and, collectively, won. They created a Lake Wobegon illusion: everyone was above average. The programmers didn’t. They ratted each other out to management– for nothing in return. Consequently, they lost. As a group, this left them with less autonomy and more managerial oversight, which meant more of that thing that programmers claim to hate: politics. We all know that corporate programming is extremely political and hate the fact, but few of us have insight into why it’s that way. It’s because we’re so bad at politics that political problems remain unsolved for years. If we simply learned how to get good at politics, we’d end up spending less time on it, and have more time and emotional energy for the work we enjoy: creating things.

It’s always best, for the workers, to leave management in the dark as to which people are the high and low performers. Obviously, low performers benefit from this. (“But who cares about them?”, asks every reader, “Since that couldn’t possibly be me.”) What’s less obvious is that high performers also benefit from opacity of the performance hierarchy. Why so? If management knows (or thinks it knows) exactly who the high performers are, it only needs to treat about 10 percent of the people being managed with any dignity. The middle 80 percent aren’t perceived to have the credibility that would make it risky to mistreat them. Making things miserable for the middle 80 percent isn’t management’s goal, but it can be an effective way of exerting leverage over the top 10 percent, who might find themselves thrown back into the mid-pack (by, say, being assigned less glamorous work) if they aren’t obedient. Companies want their middling employees to be unhappy with their status. Why? An analogy would be the decline, over the past 20 years, of service and comfort in economy-class airline seats. The airlines don’t do that because they hate economy-class passengers (they don’t care, either way, about them) but to sway those who can afford business- or first-class tickets, but who flew in lower classes in the 1990s when economy-class flight was more tolerable. Employers make it annoying to be a 50th- or 70th-percentile employee not because they hate their average people (again, they don’t care either way) but to put some fear into the top performers. However, if management is somewhat unsure about who is a top performer and who is not, this forces it to treat a larger number of employees with dignity as each might be a key player.

Furthermore, I’ve observed (from many angles) a number of terminations and what I’ve noticed is that it’s neither low performers nor high performers (“tallest nail”) who are most likely to get fired or laid off. Companies can adapt to consistent low performers, and they aren’t stupid enough to throw high performers overboard unless they burn out. Instead, people are most likely to be fired when there’s a change in performance level. Low-to-high is dangerous because shortfalls that were once blamed on inability, and forgotten, can be perceived to have been deliberate. It can open old wounds when someone who was once tolerated as the runt of the litter is now in contention for meaningful projects or promotions. High-to-low is even more dangerous, because it’s seen by management as an immediate risk to morale. If management sees a 90th-percentile worker drop to 60th, she’s still productive, but the fear of contagion will encourage management to isolate her and possibly to fire her. The fact that a 60th-percentile worker adds more business value than her salary costs doesn’t matter; management is more interested in holding up the masquerade of every employee working as hard as he possibly can, which is challenged when a former top performer falls into the mid-pack.

When someone drops from the 90th to the 60th percentile, that person’s literally below expectations. Literal-minded engineers are wont to turn on her, for that reason. This is, in my view, stupid. We all have fluctuations in performance. It’s going to happen to every single one of us: that experience of setting high (and unsustainable) expectations, until reality intrudes, is universal for people who try to do hard things. It’s a part of the human experience. I’d much rather help this person, protect her politically if I can, and have her as an ally. She’s already proven that she’s highly capable and, when she gets her groove back, I’d like to have her on my side. This is how MBAs work with each other, but it’s not how programmers think. This is precisely the collective intelligence that I’m talking about.

It is, I’d argue, often politically beneficial to protect a harmless low performer, even if you’re a high performer. Now, I’m not talking here about negative performers who cause problems, either due to incompetence or malevolence or stupidity. Those have to go. The good news is that the truly, incorrigibly toxic people are rare: maybe 1 out of 50, unless your company is absolutely terrible at hiring. When it comes to the productive but merely-below-average low performers, I have no problem with letting them stay. If they want to better themselves and become high performers, I’ll mentor them. If they don’t, then I’ll ignore them (as they desire). It’s not my company, and they’re not really hurting anyone as far as I can tell. They cost slightly more than one would pay to replace them, but they’re not going to sink the company. I don’t have an ethical issue with the company choosing to fire them, but I’m not going to help management do it; if I did, I would (a) gain nothing, (b) hurt someone, and (c) risk making a career-long enemy. I’d much rather protect that person and increase the odds that that person (who might become a high performer in another context) likes and protects me in the future. If the low performer is a lifelong loser, then it probably doesn’t matter if I rat him out to management. I won’t lose anything, but I won’t gain anything either. If, however, the low performer is a capable person having a bad year, then I make an enemy, for the benefit of a company that would toss me overboard as soon as it thought that I was a “low performer”. No thanks; I’ll protect his secrets.

If technologists protected each other and worked together, in the same way that executives have, then we could change the world not only for our benefit, but for the world’s benefit. Right now, we work so much harder than the caste of private-sector social climbers called “executives”, and get so much less in return. We’ve lost our own industry. If the right people were in charge of our industry, we’d build better technologies and solve more interesting problems and, to boot, make a lot more money.

I recognize that the statement above is a bold one. In fact, it’s hard to believe. The world is increasingly taking stock of Silicon Valley and not liking what it sees. It sees sexism, because VCs fund unqualified, narcissistic young founders based on connections and “gut instinct” instead of talent and capability. That’s not a part of our culture as technologists, but of one that’s been imposed upon us. It sees San Francisco gentrification, because the VCs fund no-remote monoculture shops almost exclusively, forcing people to live in that already-congested city, even though most have no other reason to want to be there. It sees spoiled engineers building products to solve the problems of prematurely affluent goofballs instead of rolling their sleeves up to work on things that matter. That’s what the rest of the U.S. is beginning to think that “we”, as technologists, are. Our reputation is being lost, because our industry is run by people who diverge not only from our values as technologists, but from common decency. When the public sees billionaire venture capitalists who believe women shouldn’t vote or founders’ callous, offensive rants about San Francisco’s working-class population, that’s what the rest of the world thinks we are. We can fix this, but we have to take charge of our industry.

We know who are enemies are. The Silicon Valley elite must be discarded. They have damaged our industry and slowed innovation and, with their antics, are putting our reputation at risk, too. What we need to be better at is making more friends outside of our silly tribal boundaries. For example, we shouldn’t be so quick to reject “business people” as a tribe or group. Rather than resent them for what they have accomplished, as a collective, we ought to learn from it. They’ve been pooling connections and resources while we’ve been drawing lines in the sand by saying “I won’t work with Java programmers” or “I refuse to hire anyone who doesn’t want to do Scrum”. If we had done what they were doing– putting aside differences and working together– then we might actually have a technology industry that reflects our values. More to the point, we’d get more respect and more money, as well, if we could get past petty differences and work together in an intelligent way.

The past ten years have taught me that individual intelligence is very overrated. It shouldn’t have surprised me. Organizational and collective intelligence are far more important, and we as programmers ought to develop them. The quickest way to do this is to reach out to people who already have successfully organized around their own interests. Why do Harvard Business School graduates end up running the business world? They work together, they pool resources and connections, and their first impulse is to cooperate rather than compete. We need to learn this from them, and fast. We’re losing our industry, and it’s time to win it back.