Open Source, Tech, and Tribalism

The open source community can be a turbulent place, and this turbulence often plays out in public. Periodically, people leave a community, and when they do, the swirling drama can be fun or bemusing from a distance. The “Why I’m leaving community X” blog post from a prominent Community X member is common enough to qualify as its coming-of-age milestone.

But recently, as I found myself and people I care about involved in one of these situations, I no longer had that bemused objectivity. Wait a minute, Community X is my community, and it was being harmed. I felt personally attacked. I watched others become defensive, which seemed to justify my own feelings.

As I started seeing lines being drawn, I realized that my reaction over someone deciding not to use a thing that I use was putting relationships at risk.

I had to stop and do some personal soul-searching around this topic, so I’ll try to be sensitive to the fact that others may, like me, have their identities wrapped up in the various communities and tribes they belong to. This is tribalism. It’s perfectly normal, but it’s crucial to understand, and I don’t think it gets its due when talking about open source.

A person could create a college-level course defining and exploring tribalism. For the sake of definition, I’ll leave it at this: Tribalism is the act of attaching one’s own identity to a shared group identity.

And it’s a tough one to fight: as a pre-programmed default, tribalism was key to the survival of the human species for hundreds of thousands of years. 

Coalitions, communities, tribes, and cults: a spectrum

Let’s call this the identity spectrum: the degree to which one’s identity is subsumed by the shared identity of their affiliation with a group.

Coalitions are, essentially, “frienemies”. A federated group of people, in Ayn Randian self interest, unite to achieve some common goal.

Communities are also loosely united by a common goal, but often act in the group interest above self-interest.

Tribes are communities that are bound by a shared identity as members.

Cults are a tribe that shun all identity except as a member of the tribe.

The tribe of open source

It’s easy to spot an open source developer from across a crowded room, as we usually broadcast our preferences. Borrowed perhaps from skateboarders, we wallpaper our laptops in stickers representing our interests. Everything’s fair game: Products we use, technologies we love, perhaps even our favorite My Little Pony character.

This was a big deal for me.

I’ve felt like an outsider for pretty much my entire life. Even my other “tribes” (professional, religious, etc.) never really fit me quite right, until, at 30 years old, I discovered a new sense of inclusion and belonging in the software community.

Like most tribal affiliations, I got some amazing benefits: lasting friendships, support, and a sense of purpose outside oneself. As a new developer I was welcomed, guided, mentored, and offered opportunities in a way entirely new to me.

And thanks to the network of open source developers on Twitter and elsewhere, I now know hundreds of wonderful people in cities around the world who share many of my interests, passions, and values. I can visit a conference on the other side of the country and be welcomed as if I was a longtime neighbor. It’s amazing stuff, and it deepens my faith in humanity every time I experience it.

And I should take a moment to note that I do not have the GitHub profile of a prolific open-source contributor. GitHub is not my CV.

I have my own ways of helping: writing, organizing, hiring, etc., and no one has yet stopped me to tell me I’m a fraud and kick me out of the community. In open source, your best is good enough. (Perhaps that’s just until you manage a popular project, but that’s another post.)

Tribal affiliation as a shortcut

The tribes I belong to offer some great shortcuts in describing myself to people: Rubyist, Javascript programmer, Embereño, Mormon(ish), Beatles fan.

These are great for allowing someone a small insight into my activities and interests. A shared interest in Javascript development means I’m probably game for interesting conversations on the subject. Knowing I’m Mormon lets people know I’m a pretty good bet as a designated driver.

But if I’m not careful, it can be easy to slide toward the right side of the spectrum, and start letting these shortcuts define who I am.

Bad tribal habits

If we’re not aware, we often fall into habits programmed into our brains from thousands of years before we were born. Here are some common net-negative tribal behaviors:

Blind evangelism: A sense that your tribe’s cause is a one-size-fits-all solution, and that the entire world would be best served by relentless evangelism until they join.

This allows you to feel confirmed in your belief, but it erodes empathy for the desires and needs of others.

Buying into one ecosystem: Have you ever been to the home of an Amway family (or lived in one, as I did)? All of their products are Amway. Is Amway shampoo the best? Their detergent? Eyeliner? It doesn’t matter, because the Amway families are so financially locked into the system it doesn’t make sense for them to buy anything else. (But if you ask an Amway family, yes, the Amway everything is the best.)

Using Windows makes me physically ill. Is Windows really that terrible? Or am I conditioned to think that Windows is terrible because I’ve spent a decade building an Apple fortress? Either way, counting business expenses, I fork over the cost of a decent car, every year, on Apple products.

Narcissism of small differences: Few things divide tribes more sharply than being ideological next-door neighbors.

It pains me greatly when I see communities (in religion and in technology… but I repeat myself) who all want the same thing bicker incessantly about the right way to do it.

Burning the heretic: People who speak against a tribe are often vilified. And you’ll rarely see as vitriolic a reaction as when a person leaves a tribe. And if they don’t have the decency to go quietly, they receive ten times the furor, thus justifying their decision to leave.

It’s enormously satisfying to burn the heretic. When someone leaves the tribe, they’ve just questioned our collective identity. Our rightness. Our specialness. The natural reaction is to fight back, and invalidate that person and their obviously wrong opinions.

But know this: Every time you defend a tribal identity, you sacrifice a little more of your own. And a tribal identity is incredibly fragile, encouraging defensiveness and fear.

Cult behavior: when tribalism turns evil

What’s ironic is that people who are opposed to a given tribe are themselves defined by tribalism. In fact, the notion of “enemies” pretty much only exists at the tribe/cult end of the spectrum.

For example, consider the childish, abhorrent behavior of those within the “Gamergate” pseudo-movement. It’s a form of tribalism carried to the “cult” extreme. They’ve spent so much energy defending an inherited group identity that their individual identities are completely subsumed.

This invites the mental laziness of stereotyping those outside your tribe, dehumanizing them to the point where violence becomes a natural-seeming option. Opposing, heretical voices so threaten the fragile identities of the group members that the offenders must be silenced.

It’s a textbook example of the danger and potential dark side in allowing a group identity to become your only identity.

Taking back your identity: a self-check

After all this, you might think I’d warn away from tribes and tribalism, but that’s not my point. The trick is simply owning your own identity.

Personally, I don’t enjoy coalitions. I have friends who say “get over it, these are just tools you use to make money”, and that’s great for them, but I like communities. I even like tribes, when I’m on guard against my biases. Cults, though… I’ve had enough of those for one lifetime.

Whatever your personal preference, my request, my plea, is this: be aware. Keep some self-check questions at the back of your mind:

Do you define yourself by your job? It’s easy to catch oneself saying “I’m Prestigious Title X at Recognized Company Y”. Or “I’m the creator of Cool Thing Z.” It’s incredibly tempting to lead with this stuff when talking (or thinking) about yourself.

Does your social media profile offer any hints? When given 140 characters to describe yourself, what do you say? “Cat expert, sandwich artist, alligator hunter”? I mean, that’s super cool, but are you 100% sure that’s who you are?

Do you perhaps feel like you are enlightened in a way that others aren’t? A good test of this is how much of your time you spend evangelizing the things you like vs. listening to things others like.

How do you react when someone leaves the tribe? Do you write them off? Get mad at them? Gossip about what a huge mistake they’re making?

These are your cognitive biases. It’s OK! They’re helpful in daily life. But becoming aware of them, while painful, is crucial. Every bias you recognize, acknowledge, and work to compensate for allows you to reclaim more of your individual identity.

What owning your identity buys you

As you internalize more of your own identity, it becomes less fragile, and you’ll find the freedom to enjoy the benefits of participating in communities and tribes without the same drawbacks. It increases your “cult resistance”, lowering your susceptibility to manipulation by sociopaths, which is pretty handy in the workplace.

You’ll be able to manage and maintain cross-community relationships, which often has a positive effect on all sides. You may even find yourself as an influence for good, helping focus community efforts away from tribal wars, and toward shared purpose and inclusion.

This is far from a complete formula, but separating personal from tribal identity is a crucial step in truly being yourself, which, as far as I can tell, is a key ingredient in living a happy, regret-free life.

A few cautions on open source and tribalism

If you think it’s all about the code, you are deeply and dangerously mistaken. Any person can write code, but participation in an open source community absolutely requires understanding and empathy around basic human behaviors. If you can’t accept that responsibility, prepare for a pretty lonely and frustrating road. Ignoring this means you’re likely to run roughshod over the feelings of others and cause a lot of harm to people and your own community in the process.

When you’re part of a community, you’re an ambassador. Your responsibility is to embody the kind of community you’d like to see, because those are the people you’ll inevitably attract to join you. It doesn’t matter whether you like it or not, or whether you go on TV to say “I’m not a role model,” every public interaction you have is someone else’s window into your community.

When someone leaves your community, they’re not betraying anyone. People’s interests change. Their preferences change. They may even take occasion to vent frustration with your own community, tools, or ecosystem. That’s OK too. Related: if people defect from another community to your community, it’d be wise to let them know that disparaging their previous community is poor ambassadorship for their new community.

Get out of your bubble. I spent my first few years as a Rubyist feeling a sense of superiority to PHP developers, despite never having written a line of PHP. Now I’ve interacted with so many communities that I have a deep and abiding respect for anyone who builds things in the toolset of their preference.

Cross-community competition is less valuable than cross-community pollination. In free-flowing ecosystems, you get the benefit of people taking the best of a different community and trying to bring it to the new community. Tribes that prefer the “way we’ve always done things” miss out on these improvements.

And lastly, a piece of advice I received a few years ago:

Don’t yuck someone else’s yum. It can be unfathomable to me that someone would use some outdated, obtuse, or clearly-inferior technology to get their jobs done. If they’re doing it with a smile on their face, trying to make them realize how wrong they are is petty, egotistical, and unkind. I’m as guilty of this as anyone I know, and have worked to add “don’t yuck someone else’s yum” as a mantra for myself.

I haven’t yet seen an argument about tribalism that wasn’t also an argument against it. I hope this helps make a little bit of a case for the value of hopping into a shared culture and identity with people, just so long as you know who’s in charge of your own.

Closed allocation: A failed system of control

A couple of years ago, I found myself boxed into a corner. I wanted to become a developer, but my workplace kept pigeonholing me into a management role, where I would break down (very important!) tasks to give to our other, more experienced developers.

Thanks to an intervention by a brutally honest friend, I found the strength to basically quit one (very important!) job internally to become a developer. I got to stay at the company, but took on an entirely new role, letting the old one languish and die. This was very scary at the time.

Then, six months later, my prior (very important!) position was eliminated and everyone else performing it was laid off. But I had left that role to become part of a central, truly indispensable team that was regarded as the engine of innovation for the company.

All the stuff that the organization told us was critical was actually of no long-term benefit, even harmful, to the company. The worst part is that we, the performers of those jobs, knew this, but couldn’t do anything to change it.

This is the curse of closed allocation.

The article: You should read it

A couple of months ago, I read an article by Michael Church that gave voice to many of my recent thoughts on company culture. It challenged me, and although I disagreed with some of its prescriptions, I believe it’s well worth your time.

It also taught me some labels for a critical distinction in corporate cultures: open allocation vs. closed allocation.

These terms help define a unified theory that pulls together the differences between older-industrial-revolution-era cultures (think Goldman Sachs or the military) and post-internet-era cultures (such as Netflix, Valve, or Github).

Open vs. closed allocation: what’s the difference?

Closed allocation is the traditional system of having organizational leaders translate a company’s mission into a specific set of priorities and projects, then creating a management layer to break these down into tasks, which are then delegated to employees.

Open allocation is a radically different system of having organizational leaders communicate the company’s mission to all employees, skipping the management layer, and offering the employees complete self-direction and self-organization.

Closed allocation relies on a scarcity philosophy and zero-sum math. There are so many things to be done, and so few hours. Employees should leave the decision-making to us and perform their tasks quickly and well.

It’s also pretty cynical: If people aren’t told what to do, they’ll do the wrong thing. If they aren’t monitored and prodded, they won’t do anything at all.

Open allocation systems operate on an abundance mindset and exponential math: If people buy into our goals and apply their passion and talent, they’ll uncover paths to success that we can’t even envision. 

Open allocation is the Trust portion of the culture triangle carried out to its maximum. If we entrust our vision to good people, they’ll focus on solving problems that are truly high-value.

What about drudge work? Doesn’t it just pile up?

The number one fear I’ve heard from people regarding open allocation is “but what about the work no one wants to do?”

First, it’s important to break these kinds of work apart.

Michael defines a matrix along two axes: A work’s importance to the business and its pleasantness.

I. Pleasant/Unimportant (R&D) Developers are all too happy to experiment with new techniques and technologies, or to rebuild an existing system from scratch. Google calls this “20% time”, and open allocation shops don’t place a limit on it. While activities in this quadrant don’t appear to have immediate value, letting developers “play” produces incredible long-term value for businesses. In fact, nearly every major innovation from Google in the last 5 years has been from this “20% time”.

II. Pleasant/Important (High-visibility projects) Shipping new features is fun, and there are plenty of intrinsic organizational rewards. Knocking out a bunch of small, quick bugs or features carries an immediate, visceral reward. Both open and closed allocation systems do this well.

III. Unpleasant/Unimportant (Junk pile) Developers, by default, will avoid unpleasant tasks that add no value to the business. It’s why they hate meetings like vampires hate sunlight. (Some developers hate sunlight too, but this is unrelated.) A huge amount of time in closed allocation systems is wasted here, and it’s virtually eliminated in open allocation.

IV. Unpleasant/Important (Maintenance) I’ve sometimes heard the term “maintenance developer” used as a pejorative. But developers doing “maintenance” are the unsung heroes. And here we are. This is what people fear losing by moving to open allocation.

First, let me attempt to unburden you of the belief that this work gets done or done well in a closed-allocation system. Most likely, this work is being picked at and pushed around like the steamed carrots on a 4-year-old’s dinner plate.

And this is where Michael and I part ways. His advice is to incentivize, which is yet another tactic that has been proven to have the opposite of its intended effect. (You’ve probably already seen this video, but it’s a great, concise explanation of why.)

What I’ve noticed is that if you have a collaborative team, the unpleasant tasks carry their own intrinsic rewards within a team. The deepest desire of many of my favorite developers is to make their work and that of other developers easier and less tedious.

Open Allocation gives you rocketships

It’s only in closed allocation systems that developers quietly accept work that comes to them on a conveyer belt. In open allocation, developers will automate the work that comes in via conveyer belt so they can go do something more interesting.

Competition between ideas, not people

When what you work on is not your choice, the only influence you have is to try and compete to get better work. People compete to avoid doomed, unpleasant, or unimportant projects and to get assigned to high-visibility, high-impact work.

In fact, management often views this as a valid mechanism of control, and actively fosters competition between teams or team members.

In a closed allocation system, people compete for the right to work on good ideas, while in an open allocation system, ideas compete for the right to have people work on them.

Competitive environments add an unnecessary layer of stress and interpersonal discord among team members. This leads to burnout, causes good people to leave, and inspires people to put their energy into “managing perceptions” rather than producing excellent work.

My experience is that the only environments that create lasting value foster a collaborative environment where the reward structure is tied to making your team better, rather than being better than the rest of the team.

Either way, a company will grind something up in the course of making progress. But it’s up to leadership to decide whether ideas or people are the grist for that mill. And grinding people instead of ideas turns out worse products. You’d think this would be an easy decision, right?

If open allocation is so great, why are so few doing it?

Closed allocation is the default for almost all companies. If open allocation is so superior, why hasn’t it immediately become the go-to organizational structure for new companies?

First off, almost every company starts with open allocation. It’s the DNA of a “startup” or “small business”. But amazingly, no one seems to notice as the open allocation inherent in a 5-person company starts closing up, management starts getting injected to wrangle the chaos, and employees start losing their voices and autonomy.

But the question stands: Why is closed allocation the dominant philosophy?

  • It’s how you manage people who don’t want to be there. If someone’s job is to sew a boot to its sole at a rate of 500 per day for minimum wage, it’s conventional wisdom that they require external motivation to stay on task at maximum efficiency (although this is debatable).
  • People are conditioned for closed allocation. Public schools, churches, and most areas of modern Western society condition people that how their time is spent is ultimately decided by those “in charge”.
  • Change is scary. Every part of every organization is highly optimized, even dependent, on closed allocation systems. Most people in closed allocation systems fear the increased responsibility of an open system, even if they’d excel in it.
  • Lots of other reasons. It’s a mechanism that provides stakeholders with a feeling of control over chaos. It protects people who make decisions, even if they themselves are unneeded. (When have you ever heard of a management team opting to lay itself off?) Maybe the company is hiding from the fact that it has no compelling vision. But ultimately, the fact is that everyone in a closed-allocation system eventually buys into it, even if they complain about it.

But how do I know who to fire?

This is the other question I’ve heard about open allocation. How do you know which employees are valuable and which are harmful without targets, measurements, or stack ranking? Michael Church’s article covers it well, but in short: you’ll fire fewer than you’d think. People will find more ways to contribute in an open allocation system than if they’re pigeonholed into a rigidly-defined role.

Open allocation systems only let go of the people who are so political, passive aggressive, or poorly-performing as to cause a serious morale drag amongst your other team members. It will be obvious who doesn’t fit in your open allocation system, because their team will share a set of concerns and will have tried everything they could think of to make them successful.

Ignoring this can cost you your best people, even your business

At most companies, try to talk about turnover, and you may be shocked to encounter a “fingers-in-ears-lalalala-can’t-hear-you” level of denial. But this makes sense in closed allocation companies.

To confront how, when, and why employees might exercise their right to leave is to realize that 100% of the control closed allocation offers is an illusion. Each human being has a limited tolerance for being treated like a puppet or a cog. And at some point, they’ll run out of tolerance and find a reason to quit or be fired.

Losing key employees is the most expensive thing that can happen a company. Finding, training, and growing talent for knowledge work is ridiculously expensive. That’s to say nothing of the fact that at smaller, wobbly-kneed startups, high turnover could sink the company.

By the time you actually start experiencing turnover, it’s already so late in the cultural decline that no one seems to know what to do. So, executives tend to go into deep denial.

I am not aware of any studies about the difference in turnover between open- and closed-allocation shops, but Github has not lost an employee yet (although they have fired about a half dozen of their 150+). I can promise that when numbers on open allocation (non-) turnover are finally run, a bunch of MBA-types are going to start taking notice.

Can’t I just use some components of open allocation?

Short answer: No.

Much like any ground-up rethink of an existing system (such as the Getting Things Done system or the Paleo diet), you can’t sample pieces to see how they work individually. It’s a package deal.

I’ve been inside multiple companies that decided to “try out” these open allocation systems. And I can promise what will happen is company leaders will quickly realize that almost every person in the building is dependent on this closed allocation ecosystem, and go back to what was comfortable. Every time.

In fact, I can’t point to a case study of a company ever converting, in part or in full, to open allocation from closed allocation. I’m not saying it’s impossible, but I can’t advocate it. What I am advocating is that high-performing people start selecting themselves into open allocation environments, and as they found companies, to build and protect an open allocation system within them.

I’m stuck in a closed allocation system, what now?

Unless you work in a 5-person startup or the government, chances are that your workplace is someplace in between these two extremes, with a strong bias toward closed allocation.

First off, you should know that you have more room than you think if you throw some elbows around and redefine your job. If you’ll take a bit of risk, you’ll find more ability to define your own job than you previously thought. If you assert yourself as someone who understands your job well, and that you understand the company’s goals, you’ll find yourself with more input into the kind of projects you work on and they way you do them.

The sad truth is that ultimately, if you are a high performer, you will find yourself out of patience with the system you’re in. If you’re not careful, you’ll let this frustration drive you into the arms of another closed-allocation system, unaware that the cycle is simply beginning anew.

But I hope you’ll break the cycle and select for open allocation cultures (or go start one yourself), rather than reacting by simply job-hopping.

Who should switch to open allocation?

Imagine your employees, highly engaged, working on the exact thing that rings their bell, finding novel solutions to your most important problems, and pushing your organization closer to its ultimate vision, automatically, without needing to oversee every detail.

This is the promise of open allocation. If your organization has a true vision and a culture of honest feedback, you stand to benefit greatly from this style of management. If you lack either… well, open allocation might not be a fit.

But if you run a shop that you’re confident has vision and feedback, you may wonder if it’s possible to try at all. You could create this type of team that reports directly to the CEO and that has full autonomy, but not without majorly disrupting the rest of the organization, which I’ve seen inspire jealousy and backbiting. It’s treacherous territory, but if you’re bold enough to try it, you’ll discover that you can attract and keep the kind of talent that does great work autonomously.

Lastly, if you run a closed-allocation shop, make note of this warning: Open allocation shops are so fast, so nimble, and have so much energy that if a competitor runs one, they’ll someday be the Muhammad Ali to your Sonny Liston.

You get to choose which to be, but make no mistake, you will be one or the other.

Ali vs. Liston by Dave Rr via Flickr

“A players” and redefining your job

credit: nettsu via Flickr

Not long ago, I engaged in a conversation on Twitter about the de-motivating effects of placing extrinsic motivators on A players.

This resulted in a fun discussion about the nature of motivation and whether the concept of an “A player” is even a useful classification.

I’ll leave the discussion of extrinsic-vs-intrinsic motiviation stuff to Dan Pink. But what I don’t see is a really coherent explanation about what it means to be an “A player”, how a person becomes one, or whether the term has entered the MBA-buzzword graveyard with “proactive” and “synergy”.

Is the term “A player” fair, or even useful?

Popularized recently by the management style of Steve Jobs, the term “A player” has come into broad usage by management types who wish to sound knowledgeable. Which, sadly, is where good business terms go to die.

That said, the term does carve out a spot in your brain to understand that not all people in an organization are equally valuable. “A player” refers to the power plants of your organization: the people who supply an abundance of high-quality output.

This means that there are “B players” and “C players” who produce less useful output and are more likely to be sort of “along for the ride” in an organization.

“A player” is a role, not a permanent label

Yes, it is dangerous to use a term that looks and feels like a classification or labeling system for people, especially one that implies a judgement as to that person’s value. But it is a hard truth that some people are more valuable to an organization than others.

That said, it’s crucial to note that “A player” refers to a role a person plays. I’ve been an A player, a B player, and a C player at various times in my career, and sometimes even at the same job.

Identifying an A player

Whether you’re looking to hire and keep A players or trying to figure out if you are one, here are some observations I’ve made about people I’ve seen as A players:

Has a trail of accomplishments: A players leave behind visible, tangible results of their work, as they are results-oriented. A players ship.

Seeks out feedback: They don’t reject criticism outright, and actually seek feedback, since their ego is less valuable than getting something done.

Has confidence in own abilities: They’re not confident as in boastful, but as in the opposite of insecure. A players rarely shy from a challenge, knowing that it is a matter of patience and work to see something through.

Not big on seeking permission: They tend to choose the work they think will have the biggest impact and go for it, steamrolling obstacles in their way.

Self-evaluating and self-correcting: A players tend to introspect, are driven to improve themselves, and correct mistakes quickly.

Not interested in gossip: A players view “office drama” as a needless source of distraction rather than fodder for conversation.

Helps others succeed: A players are inspired, rather than threatened, by the success of their peers. They actively seek to help others become successful.

By this definition, B and C players are often insecure, complaining about office politics or “playing the game” against their successful peers. They hide their work, rarely shipping, in fear of criticism. They tend to wait for permission to move forward. They tend to wait for a lot of things to be in place before moving forward.

Redefining your role: How to become an A player

I believe that A players are generally B players who figured out that they alone are in charge of when they ship, what they ship, and the quality of their work.

The most important factor in becoming an A player is whether you can attach to a goal that is larger than your ego and insecurities. One that is worth risking failure for. One that is worth breaking the cycle of permission-seeking for. Preferably one that can be accomplished in a matter of a few weeks, lest you burn out before completing the goal.

With this goal burned into your brain, you’ll pull together the resources you need to accomplish it. You’ll naturally find someone to help you with gaps in your skills, because you’ll want to see this through.

You won’t have to work very hard to eliminate distractions, because the distractions that seemed so sweet and tempting before will taste bitter to you now. The desire to ask permission will be gone.

And once you’ve accomplished it, you’ll never want to go back to B-player-style work again. You simply won’t be able to tolerate it. It’ll drive you crazy.

Then, the work begins again of finding the next goal that is similarly motivating.

Yes, finding that goal is easier said than done, but I’ll bet you can find it if you pay attention to what is around you.

How to lose your A players

Many organizations don’t actively identify their A players until they start to leave, and management staff, in a panic, begins some misguided effort to get the remaining A players to stay.

Steve Jobs famously said “A players like to work with A players. B players hire C players.” This, of course, comes back to the fact that B and C players aren’t confident in their abilities, and need to hire people that won’t show them up.

A players form ad-hoc alliances whose goal is to ship, while B and C players tend to form committees whose goal is to prevent things from being done wrong.

A players don’t react well to committees, forms, or bureaucratic processes that add friction to the act of building and shipping.

Each point of friction adds up until A players realize that they aren’t able to operate at their full capacity. They may even verbally warn their management (who often aren’t receptive, or make empty promises of change). And being high-value employees, they know they can succeed somewhere else that promises less friction.

It’s a lifelong process

Some of the A players I’ve met seem as if they were born that way, but for most of us, it’s a lifelong process of self-refinement. A lot of my struggle is to subjugate my ego long enough to really seek and apply feedback.

But to individuals, I can promise that the benefits of developing yourself into an A player are abundant. No one has the world in front of them quite like high-performing individuals.

And to organizations, the benefits of cultivating an environment that rewards A-player behavior are even greater. If you’ll identify and reward your A players, they will drive a culture of results and shipping that defines the best companies in the world.


After posting this, I realized that people may take the wrong message from all this. If you’re reading this, you’re probably an introspective person. If you’re introspective, you have a leg up on 95% of the population. You’re well on your way and very well could be an A player already. Just because there’s still room to grow doesn’t mean you aren’t amazing already.

So take any self-criticism with a grain of salt, and realize that the fact that you’re even evaluating yourself puts you in the category of people I’ve defined above as A players.

The culture myth

Petri Dish by PNNL via Flickr

A couple of years ago, while at a bustling internet startup, our CEO bought everyone in the company a copy of Tony Hsieh’s Delivering Happiness. Although it wasn’t my favorite business book, it was nice to learn about the central role of culture at a remarkable company.

After we’d all read the book, there began in earnest an effort to create a “corporate culture” that showed how fun and unique we were, and that would attract top technical talent. Suddenly, Nerf guns and toy helicopters filled the office, but something about this effort rang hollow to me. I couldn’t put words to it, and I left for another opportunity before I gave it much of a chance one way or the other.

The very next company I worked for had a similar cultural focus, only dialed up to eleven. People whizzed about on scooters while new employees were given a tour through our deeply-held organizational values (which were literally painted all over the walls).  After a few tough months, the CEO openly wondered what had killed the culture, and vowed to “bring it back”. It was painful to watch, and made me wonder how any company can foster great culture when even this culture-obsessed workplace could go south so quickly.

I’ve since given a lot of thought to what makes up an organization’s culture, and I realized that this obsession with culture, for many organizations, is killing that same culture.

I believe that what we typically call culture is a side effect of an organization’s traits and habits. Just like a fire needs heat, fuel, and air, I believe there’s a similar “Culture Triangle”:

  1. Vision
  2. Trust
  3. Feedback

If an organization has a strong vision, high trust in its people, and tight feedback loops, it would be very difficult for it to have a “bad culture”.

In the first organization I referred to, there was a clear vision for the company and a decent feedback loop, but very little trust in the people tasked with carrying it out. I hear they’ve subsequently improved this dramatically, and also that they’re doing quite well.

In the second company, there was never a strong vision, other than to have a great culture (which I think actually distracted from the need for a real vision). More tellingly, I watched trust evaporate as we started missing targets and the company’s leadership took more and more autonomy away from its staff, evolving into a command-and-control organization.

Why startups lose their culture

This story is so common it’s generally considered inevitable: the fun, breezy startup culture becomes more staid and bureaucratic, usually around the 15-30 employee mark.

In a one-to-ten-person startup, awesome culture is essentially automatic. Almost no startup survives its first stages without strong vision, deep interpersonal trust, and lightning-fast feedback loops. There’s simply no start without a clear purpose, there’s no room for double-checking your co-founders’ work, and no way to screw up without it being completely visible to everyone.

As an organization scales up, layers are introduced, and strange things happen. That crystal-clear vision becomes murkier when it’s up against hitting a quarterly target. Hiring trustworthy people becomes difficult enough that employees now must be “managed” by people and policies. It becomes difficult to connect top to bottom, allowing feedback loops to take months, rather than hours.

But it’s not all doom and gloom… some companies reach escape velocity with their culture intact. Famously, Netflix and Github have held themselves up as examples of scaling high-performing corporate cultures. How do they do it?

Relentlessly protecting your culture

Creating a culture is easy, because if you have a company, you already have one. Your first three or four employees basically comprise your culture, and from there, the hard part is protecting it.

Here are some of my observations of patterns in culturally successful companies:

  1. Hire for culture. This means hiring people whom you plan to entrust with your vision and their execution of some part of this vision. This requires both trustworthiness and competence on their part.
  2. Keep your door open. I’ve been fortunate to work in very few places with “ivory tower” management, but it’s a killer for trust and feedback. You’ll know if you’re truly communicating that you’re open to feedback, because you won’t stop getting it.
  3. Have reviews, but don’t wait for them. It’s always uncomfortable to offer correction, but I’m incredibly grateful for the feedback I get on the team I’m on now, and feedback I’ve received from teams in the past has literally changed my life. Assume your team members will accept constructive feedback, because if you did #1 right, they will.
  4. Keep the vision clear. A vision is not a numeric target, but a reason for people to get up and come to work in the morning. What in the world are you changing? Building? Shaping? Who benefits?

What If…

…You hire untrustworthy or not-competent people? The temptation is often to remove ownership from people, but this is the slope that leads to a trust-free workplace. A good feedback loop should take care of most kinds of mistakes. If a person isn’t fulfilling their role, you’re doing them a disservice by letting them skate along, unknowingly missing your expectations. If they’re not a good fit at all, they probably don’t want to spend their time on the wrong bus any more than you want them on it.

…Your vision changes? Your vision is your organization’s purpose in existence. No matter how many “pivots” you make, if your company’s core vision changes often, you may want to examine whether you had one to begin with. That said, if it truly does change, you need to give employees ample time and reason to buy into this new vision (and recognize that some may choose not to).

…You don’t do reviews? Reviews don’t have to be formal, but they do require some discipline, even at great companies. Programmers are fortunate to often have code reviews, where peers look over each others’ work, offering questions for thought and suggestions for improvement (much like an editor for writers). I think this culture of collaborative peer reviews would be wonderful to carry into other areas of your business as well.

To put culture first, put culture last

The thread I see with running through the most successful, high-performing companies (and I feel that the company I’m at now is one of them) is that they tend not to wring their hands over “culture” too much; they’re very busy getting amazing things done. And who wouldn’t want to get up and go to work when you’re entrusted to go get amazing, meaningful things done with other amazing people?