Your “high bar” is wrecking your team

Near the beginning of my technical career, I worked at a fast-growing startup. One afternoon, my CEO walked into our dev area, which is something he never did. Some people in snazzy button-downs and sport coats followed him into the room, tipping us off that this was likely a show-and tell for some fancy VC-type folks in hopes of raising our Series E (or F or P or Z, who can remember) round of financing.

“And here are our developers. Everyone on this team has at least a Bachelor’s in Computer Science from great schools.”

I tried not to let my eyes bug entirely out of their sockets at this, and continued with my work. There were a lot of degrees in that room to be sure, but unless Salt Lake Community College secretly awarded me an honorary BA in Bad Sonic Fanart, none of them were mine.

But, sitting there in my sense of inferiority and exclusion, I knew for a fact I was a valuable contributor to that team! Even as a new developer, I learned fast, collaborated, and played a big part in getting our software shipped.

So when I tried to bring other people onto the team, I felt confident the right thing was in looking for someone with those traits. So after bringing in a couple of candidates I knew would make a great contribution, I was surprised to find out that my boss passed on the candidates, calling them “journeyman developers” and “not up to our technical bar”.

The cycle repeats

That’s the first time in my career I’d heard the phrase “keeping the bar high.”

A few recruiter calls later, we’d managed to hire some “star performers” with impeccable resumes who dazzled us with whiteboard acrobatics, while actual work tended to seize in the face of office politics and interpersonal turmoil.

I was puzzled by this, until I saw this happen again at another job. And again, and again. At one job, a CEO would screen candidates’ CS degrees among schools to make sure that we didn’t let in riffraff from lower-tier Computer Science programs (worth noting: to work on a team that I ran).

This rather bizarre logic planted a question in my mind: why are so many companies in our industry fixated on setting and protecting a “high technical bar” when this makes their teams worse by all measures of output, product quality, team diversity, and turnover?

Who decides what the bar measures?

Maybe before we can answer that question, we need to ask: what does a “high technical bar” even mean? That phrase carries with it a self-important sheen of “rightness” and “intellectual rigor” even as it hides a mountain of bias.

It’s lunacy to think that a software developer could contribute along only one axis, but “the bar” is almost always set along exactly one: amount of exposure to a formal computer science education.

Almost every software developer in our industry with a CS degree will tell you they “dust it off” periodically for some classes of problem, while most of their day-to-day is work they learned on the job. But the majority of technical interviews still focus heavily on the skill of solving algorithmic problems on a whiteboard or demonstrating the ability to classify algorithms in big-O notation.

That’s why all these “mastering the tech interview” blog posts and books are filled with back-of-the-book solutions to common computer science algorithmic puzzles.

So you have a “high technical bar” that you assess via puzzles whose solutions can be memorized from a “hacking the interview” book. Cool, let me know how that works out.

Maintaining the high

Congratulations! You’ve assembled your “Avengers of code” via puzzles, brainteasers, and discussions of esoteric language features.

We are a team of the best, because we only hire the best, because we have a high technical bar. QED.

And it just so happens that this reinforces the egos of team members, executives, investors, etc. At one company the CEO used to talk about how this was “the best engineering team ever assembled”, on repeat, despite zero evidence in the form of shipping software (and significant evidence to the contrary once that software actually did start shipping). Who wants to argue with someone telling you you’re the best?

But how do you keep this rolling? How do you avoid the other shoe dropping once the team is actually expected to ship working software?

Well, that’s where the shit starts hitting the proverbial fan.

Setting the bar on your team


Even after expectations move from “we hire only the best” to “where’s my software”, you’re still left with the residual effects of this culture of bar-setting. People in these cultures tend to “set the bar” for each other and expect their team members to jump over it.

This means people on bar-setting teams are sitting with their arms folded, waiting for candidates, and ultimately their teammates, to fail their expectations. And when they inevitably do, we “flip the bozo bit” and ask why we have “B players” on our team.

It’s hard for me to imagine a less healthy environment than one where a group of people sits waiting for their teammates to fail them in some as-yet-unimagined way, but this culture is very real and very common.

Helping each other over the walls


The frustrating thing about this tendency toward setting each other up to fail via artificial bar-setting is that there are very real walls that we as members of a team need to climb over to get our products out the door and solve real-world problems.

We have deadlines to hit, bugs to fix, logs to read, 1 AM pages to answer. We have customers to serve, teammates who need our help, and yes, in some cases, investors to impress at the next board meeting.

The least productive teams I’ve seen are so focused on whether their teammates should be there in the trenches with them that they aren’t focused on the fact that they’re all on the same side of the battle. They’re so fixated on making sure every hire is a CompSci superstar that they can’t see the prismatic rainbow of skills it takes to design, ship, and support software that withstands the harsh realities of real-world use.

The most productive teams I’ve been on are the ones who are pulling each other over these walls in the battle against real-world problems. No, that doesn’t mean that you can pull 10 random software developers together and have an ideal team, but I’d rather have 10 random developers who are in it for each other than 10 superstars who will bar-set each other to a standstill.

A note on “lowering the bar”

One phrase in hiring I dislike more than a “high technical bar” is “lowering the bar”. This one is more insidious, more intellectually dishonest, and drips with even more gatekeeping bias.

It’s almost always used to avoid having a conversation about including a more diverse set of folks on a team. “We want to include more diverse folks but we don’t want to lower the bar,” means a team is considering a candidate that might bring something different to the table but that “something different” is not measurable on their yardstick of Computer-Science-derived technical merit.

I think that often, these people aren’t really worried about a “lower bar” as much as the ego-threatening possibility that their formally-trained “hard skills” could be comparable to, or *gasp*, less valuable than, informally-learned “soft skills” like mentorship, compassion, leadership, or collaboration.

I know a lot of people who have a formal CS background who deeply value the skills along these other axes, and I have never heard any of them express any concern about “lowering the bar”. Just saying.

Bar-setting is a failure of management

If you find yourself on a team of people who are setting a bar for each other rather than helping boost each other over walls, it doesn’t mean the people on the team are bad. It does, however, mean that your management is definitely failing you.

What you are likely dealing with is a team that is incentivized to tear each other down rather than deliver a result together. Your management is failing to help you find and focus on a shared purpose beyond “managing the optics” of your individual performance.

If you look around and you don’t see people who are different from you, from different backgrounds, it’s likely your interview process tends to select the same “high performer” over and over again. Your management is failing to value the variety of skills it takes for a team to create and support a product.

So what can you do?

Whether you’re a contributor or a manager, changing culture is hard. Your influence may be limited. So how can you help shift away from a culture of bar-setting?

And if these things are fundamentally out of alignment with your workplace’s values…

  • You can (hopefully) leave.
  • (And if you can’t leave, maybe you can start a support group)

Goodbye bar-setting, hello wall-boosting

On a healthy team, you won’t hear a lot about a “technical bar”, but you will see a group of people focused on a shared goal, helping each other over barriers, and getting software out the door. They’re not perfect, but they don’t need to be. They tend to focus on making their customers happy, learning from their mistakes, and helping each other get better.

I’ve worked on both kinds of teams, and I’ll bet my career on wall-boosting teams over the most talented bar setters. By starting small, you can create an example of success. With success, you just might get your team to buy in. With some results and buy-in from the team, you can teach your team’s leadership that larger-scale cultural change is possible.

Who knows, if enough of us can show off what collaborative, supportive, inclusive teams can do, maybe we can bend the arc of the industry in that direction. It’s worth a shot.


You are not your company

Facebook hoodieI’ve done a lot of thinking in the past about how a person carves up their identity, and most of the time I’m comfortable with a certain level of tribalism.

In fact, my partner Charles and I have worked very hard over the last few years to subjugate our public identities (AKA “personal brands”) during conference talks and blog posts to that of The Frontside, for good reason. We have a shared goal that is larger than either of us, and we want an umbrella that is larger than us to protect that goal. (The goal itself is a topic for another day.)

So why would I have a problem with my employees telling people “I’m a Frontsider”? Or with a gaggle of employees of Cool Startup X all decked out in company swag huddled together at a tech event? Or how about when someone drops the name of their workplace with all the subtlety of James Bond’s self-introduction?

“I work at GitHub. The GitHub.”

Why would that make me uncomfortable? Because I don’t believe a company is an appropriate or safe place to house any significant portion of your identity.

You just have to ask one question: What is the exchange happening here? By tying your identity to your company…

You get: A sense of belonging, and perhaps some prestige if the company is known.

They get: An increased sense of importance and priority to your work life, a lower likelihood you’ll leave for any reason, and a staunch defender of the company… all without having to pay you more.

Basically I get more “employee per dollar” if you’re willing to identify with my company.

I don’t think people realize the exchange that’s happening here. Hell, I’m an owner of my company and I don’t like the exchange rate on tying it to my personal identity. And I’m expressly not a fan of companies using psychology to extract more value from employees without compensating them.

Charles and I are building a Brand (yes, I know, ugh) that is expected to stand in for a set of goals and values, and are willing to attach much of our public work to that Brand intentionally. But that is very different than tying it to our own personal identities.

Like us, you already tie a lot of things to your company: your time, your daily personal associations, and your best work. That’s the agreed-upon exchange when you take a job. I strongly recommend to my employees and to those who will hear me to not give up a big ol’ chunk of your identity in that deal without careful consideration.

The question that made me quit the best job I ever had

"Great Wall" by akasped via Flickr

I was grinding my teeth, I was wasting my youth
And using up my teeth

Now, I’m done chewing my nails
Hanging my head, chasing my tail
It got so bad I quit my job
Then I got a new job climbing the walls

-They Might Be Giants, “Climbing the Walls”

I was haunted by that song. From time to time, I’d realize it described my exact situation at a job, and the song would get stuck in my head. I would “vaguetweet” the lyrics, hoping to express the faintest shadow of the existential malaise I actually felt, while hoping my bosses didn’t realize I was scouting for the next job.

Yet this was a massive improvement over my prior situation.

I’m going somewhere with this, but I’ll have to start at the bottom.

Bottoming out

Four years ago, I was on the marketing team for a company that we all knew was (very slowly) circling the drain. Nearly every time a meeting was called, my heart would race, and the halls filled with chatter about whether people would be laid off. This had gone on for years, but I felt unemployable enough that I didn’t see an option but to endure and agonize.

On this particular day (December 30, 2009, but who’s keeping track), they brought the designer and me in, the last of the marketing team, and let us go. I put on a brave face, but I was crushed. I’d poured years of my life into the company, and they’d rejected me.

I cleaned out my desk, said a few goodbyes, and went home to an empty house with my wife at work and my 1-year-old in daycare. I heard a strange noise, as if someone was running the shower, and came downstairs to find that a hot water pipe had burst, caving in part of the ceiling and flooding my basement with five or six inches of water.

Gravity seemed to instantly quadruple. I collapsed into a chair, surrounded by water, unsure of how I would deal with everything that was happening, and sobbed.

But as one does, I quickly shifted into management mode, shutting water off, calling a cleanup company, contacting insurance, arranging a place to stay with family. Within a few weeks, the house was livable and I was in a new job.

Waking up

Being laid off was miraculous. First, I learned that losing my job didn’t kill me. My spouse didn’t leave me. We didn’t get our house repossessed. My kid was as happy as ever. The flooding thing was probably not a direct result of losing my job, so we’ll chalk that up to coincidence.

Just as importantly, I learned that I could interview for, land, and perform a job to the satisfaction of the people that hired me. That may sound obvious, but it was a revelation after being beaten down by a job culture that essentially said, “where else are ya gonna go?”

Most of the fear that had paralyzed me into staying in a terrible job for years was just gone. I was employable.

The seven-month itch

I’d been working toward becoming a professional programmer, a goal that seemed out of reach to me at the time, so I took a job that I thought would get me closer to my goal.

(The “breaking into the software development game” post will have to wait for later, but I was very lucky to have friends who guided me through this process, including Dave Brady, who is so good at this he’s writing a book.)

In short, after becoming disillusioned with the broken promises at one job, I’d move on to another. And then another.

All in all, over the course of 3 1/2 years, I took (and quit) five jobs, ranging from 3 to 14 months. But a pattern did start to emerge: at each job, I’d start with excitement and optimism. After a few months, I began to notice an organization’s problems, which would then fade into a general sense of anxiety and frustration, rooted in the fact that the company was a mess and there wasn’t much I could do about it.

I’d sit in the parking lot, staring at the building each morning, working to summon the will to go inside.

I always saw myself as a responsible, dependable person, so it was very difficult to look at this and wonder if the problem was me. But each time, typically after a six-month honeymoon, I’d start looking around and seeing my workplace’s dysfunction and a deepening sense that I was just in the wrong place. I’d work to improve things, then try to fake it for a while, and ultimately, I’d leave.

The dreamiest dream job ever

Then, after leaving yet another dysfunctional company, a good friend helped me find my dream job. It ticked off everything I could possibly want. Working from home on a 100% remote team. Great compensation. The opportunity to learn from some of the kindest and most intelligent people I’ve worked with.

I spent a lot of time pairing with amazing developers who also happen to be good friends, leveled up my skills as a programmer, and felt valued for bringing my own unique flavor to the team.

And my boss! He is, to this day, the best boss I’ve ever known. No one is perfect, but I could (and definitely should) spend an entire article examining what sets him apart. But in short, he is kind, empathetic, and sees his role as a protector of a team’s autonomy from organizational pressures. His reputation precedes him in this regard, so he attracts some amazing people to work with him, creating a virtuous cycle.

In every area, professionally, I’d finally hit the jackpot. To this day, I thank my lucky stars (and that good friend) for the opportunity to work on a team like that.

There’s simply no way the four-years-ago version of me, sitting in a chair, sobbing, could have even dreamed that I’d find myself in that work situation.

Things were going great. And then I quit.

What is wrong with me?

Believe me, I resisted. Strongly. I didn’t want to quit this time, honest.

I’d interacted with an open source developer several times over the last few years, online, and then in person after moving to Austin. He stuck out to me as someone uniquely worth listening to, and I was struck by how kind, empathetic, and whip-smart he was in our interactions.

Ultimately, the opportunity came up to partner with him to take a small consultancy, focus on Rails and Ember.js, two technologies I love, and grow a business and team together.

Everything about it was less attractive on the surface: It wasn’t remote, less flexible, more work and stress, and a huge (over 50%) cut in pay. Initially, I was firmly against the idea.

But these conversations started gnawing at my subconscious, and a sense began to grow in me that I was heading down a path that wasn’t mine: a path of comfort at the expense of seeking my own destiny.

The deciding question

For me, it came down to one question:

“Will I regret not having tried?”

I was actually angry to have to admit that the answer was an unequivocal “Yes.” I couldn’t run from that fact.

There are a lot of reasons backing that up that I won’t delve into here, only that my heart knew with crystal clarity something that took me weeks to begrudgingly admit to myself. That I prefer adventure to comfort. That I can’t be happy only exercising a small portion of my capabilities, no matter how great the other circumstances are.

What I’m up to now

So I quit my dream job to help run a software consultancy. My boss, in typical fashion, was amazing and magnanimous about the whole thing, even though I was very embarrassed to leave so soon after starting.

So now, I’m working with The Frontside, an Austin-based software studio focusing on Ember.js and Ruby on Rails applications. We think we’re on the leading edge of the next wave of web applications, and it’s been a thrilling ride so far. I think the two of us can’t help but build something special, and I’m excited to start showing it off to the world.

My partner, Charles Lowell, is a mensch. I’ve learned so much from him over the past few months, not least of which that running a business is hard. From sales to hiring to the technologies I work in, the learning curve has actually been incredibly painful. But those lessons will have to wait for another day.

So what’s the point?

So am I telling you to quit your job? Obviously, that isn’t the point… you could quit any number of jobs without growing as a person or advancing in your career. Here’s what I want you to get from this article: It’s time, right now, to think hard about the next step in your career.

The next real, meaningful step is not a title, salary, or lifestyle upgrade. Those are side effects, and rarely (if ever) wind up justifying quitting one’s job.

The meaningful steps include things like:

  • a greater understanding about what you want and what you don’t.
  • new relationships and friends for life.
  • lessons that deepen your character.

I used to feel permanently glued to my job, so when I lost it, I felt like I’d lost everything. Since then, I’ve learned when to stick with a job and when to quit, and they’re counter-intuitive. It was time to stick it out when I was at my most frustrated. The lesson I kept having to learn was how to shape my environment, and more importantly, myself, to find happiness amidst the chaos.

Once it felt like I’d learned the most challenging lessons and things started to click into “autopilot” mode, my heart told me it was time to move on. And each subsequent move has brought with it even more perspective and relationships.

I don’t know what’s next for me. I am excited to see if I can put my money where my mouth is and build the business I always dreamed of working for. I do know that whatever happens, having tried is one less regret I’ll have, and I haven’t for one second felt like I was “climbing the walls” anymore. That’s gotta be worth something.

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

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?