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

bar-setting

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

wall-boosting

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.

 

Why I love grumpy developers

photo by spdracerkmw via Flickr

Edit: I wrote this post 3 1/2 years ago, but never published it for reasons. But I like it so here goes:

I’ve already posted about the developer who took me aside and introduced me to programming.

But there’s a part of that story I have never publicly talked about, because it’s pretty embarrassing. But I think it’s important to share.

The lead developer at the startup I’d been doing marketing for was sort of a polarizing figure within the organization. He was brilliant beyond description and fiercely loved by his team, but some of us outside the  development team labeled him as “arrogant”, “aloof”, or worse.

Certainly, there was some tension between marketing and development, and I was the worst of them. I mistook the lead developer’s emotional distance for a lack of feelings and felt justified in criticizing him.

One day, I made a point of excluding him from a group lunch, making snide remarks about why I didn’t want him there. Inevitably, I found out later that he had overheard my cutting remarks.

Not long afterward, he confronted me and asked what my issues with him were. I started by trying to justify myself, and eventually realized, with no small amount of shame, that there was no good reason for my feelings and actions, and I apologized. We decided to try and “start over” with our professional relationship.

Well, if you know me or read this blog, you know how it worked out: He introduced me to programming and became a trusted mentor and one of the greatest influencers in my life.

Grumpy != unkind

Since then, I’ve discovered that many of the most fascinating (and sweet) developers I’ve met are often mislabeled as grumpy.

Before I go on, it’s important to make the distinction between “grumpy” and “unkind”. I am not talking about people who act like jerks, and tear down others or their work to make themselves feel superior.

I’ll use the term “grumpy” in this article to point out a common public perception, but in no way do I endorse using it to actually describe a category of people.

I’m talking about makers who are often perceived as “prickly”, “not communicative”, or “aloof”. Developers who growl a bit when an arbitrary timeline is imposed on a project, or when dragged into yet another multi-hour meeting.

I’ve now had a few years of experience in this arena, and the developers people sometimes label as “grumpy” often become some of my favorite people. Let me try to crack open a few misconceptions.

Misconceptions about “grumpy” developers

Grumpy developers are not mean.

In fact, they’re some of the kindest souls you’re likely to meet. I’ve had several developers labeled as “grumpy” (or worse) take me under their wings as I was learning, encourage me, and patiently answer my ridiculous questions, all with no expectation of reward. And I have heard this from many, many others.

Grumpy developers are not cynics.

They generally distrust people who have something to gain from taking advantage of them. Many manager-types will set deadlines, promise features, and use flattery, intimidation, or both, all in service of extracting every ounce of their worth. This leads to a guarded state that is often mistaken for cynicism.

Grumpy developers are not egotists.

The best developers have at least a glimpse of their own capabilities. They know that when faced with a problem, however unknown or difficult, it is merely a matter of time before they will have the problem solved. Far from ego, this is actually a valuable form of optimism!

Brad Pitt is in this commercial. Brad Pitt is not a developer.

Grumpy developers are not loners.

They often crave connection but may avoid crowds. They’ll choose deep, one-on-one communication over sitting in a group, laughing and enjoying life like some kind of Pringles commercial. And sitting in meetings is like the world’s lamest Pringles commercial.  So don’t be surprised when they turn down a meeting invite or “team building exercise” so they can get back to work.

Grumpy developers are not lazy. 

Experienced developers quickly learn to hate repetitive busywork. So if you have a backlog full of repetitive, menial tasks, prepare to have them stack up. But these same people will frequently work a second shift after “office hours” just to have uninterrupted work time. That doesn’t smack of laziness to me.

Grumpy developers are not pedants.

True, some developers can be pretty pedantic at times. But the “grumpy” developers are usually neither dogmatic nor pedantic when they glare over their glasses at you when you try to check in code that is poorly tested. They are wincing inside at the pain that both you and they will soon feel as a result of bad coding decisions, and they’re not shy about correcting the problem.

Grumpy developers do have feelings.

The most shocking thing to me is how much people (myself included) feel justified taking potshots at higher-profile developers, especially ones who maintain large open-source projects. No matter how accomplished, people still have feelings, and it can be difficult to remember that when we disagree with them.

Why do people label developers as “grumpy”?

I think it’s primarily for one reason: Grumpy developers do not suffer fools.

So then… what constitutes a fool?

Imagine learning that an application in widespread use had left in obvious, gaping security flaws that could compromise the data of all its users. You’d be obligated to say something, right? You might even be angry with someone who would ship software that endangers its users in this way. The person who let this happen is seen as a fool.

The person who does no cursory research before offering criticism or asking a question is seen as a fool.

The person who makes politically-motivated, short-sighted promises is seen as a fool.

The person who hamstrings developers by trying to get them to conform to the manager’s schedule is seen as a fool.

The person who cannot take criticism, who choose preservation of ego over self-improvement, is seen as a fool.

These people generally receive no quarter from “grumpy” developers. I’ve been the fool many times before, and will many times again in the future. The trick to this is not to take it personally, but to dig for the source of frustration. You’ll find it isn’t personal and is usually easily rectified.

Maybe grumpy developers are just tired. 

So here you have this group of highly-skilled, self-motivated people athat are fully aware of their own capability. And then they’re dropped behind enemy lines to sit in meetings, fill out forms, re-answer the same set of questions, and rapidly switch contexts, all while trying to carve out enough time to ship software.

And I think this generally applies to people in all creative fields. Would it be a better world if all these grumpy makers-of-things woke up with a newfound sense of “customer service”? Maybe, but I’m not convinced. In professions that require hours of solid concentration, there is a heavy penalty to be paid for being overly accommodating.

The secret to getting along with “grumpy” developers

As I mentioned earlier, I think a good start is to avoid affixing labels like “grumpy”. However you perceive their disposition, they’re people with feelings and a lot they want to offer the world.

There’s one developer in the Ruby community who’s somewhat legendary for being prickly, and I recently heard a story about him taking several brand-new developers under his wing to mentor and guide them. This has been my experience as well: many of the greatest kindnesses I’ve been shown as a developer have been from people that are often labeled “grumpy”.

Like so many things in life, the secret is not to flatter, coddle, or kowtow, but to be more interested in them as fellow humans than in what you can get from them.

(Incidentally, when you call devs “rockstars”, you really mean “racehorses”: they’re superstars now, but someday they’ll wind up at the glue factory.)

So the next time you label a developer as “grumpy”, perhaps take that as a signal that you might actually want to stop and really get to know this person, this fellow traveler in life’s journey, a little bit better.

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.

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.

Letter to an aspiring developer

Nearly 18 months ago, a person emailed me out of the blue asking for advice on breaking into software development.

He was full-time student, trying to start a career in software development, but was paralyzed with worry of making the wrong choice.

My response was applicable, I think, to anyone trying to get into software, and I’m going to leave it largely unaltered.

I want to offer some thoughts based on what I see as main themes:

1. Getting your foot in the door in software development

I had to spend 2 years taking non-dev jobs, with the express understanding that my goals were to become a software developer, before I was able to assert my role in one job as a developer (after a pretty fierce battle to do so).

Just about any dev job you get is going to be just fine. Seriously, you can relax about that. The first couple are supposed to suck. If they don’t, you won’t know what you don’t want in your own company someday.

That’s not to say you should necessarily take the job in front of you, I’ll address that in a bit.

2. Setting long-term goals

You know how you have no idea right now which direction to go in? Get used to that feeling. Right now, a bunch of Rubyists are nervously looking around as they watch their platform stabilize while JavaScript takes off like a rocket. Nothing is set, nothing is guaranteed, and the notion of long-term goals is flat-out stupid.

It’s crazy. Eleven years ago my job was to get lunch for people, and I decided I wanted to be a graphic designer. So I got a Mac and got really good at photoshop and illustrator. Then I got a video camera, learned Final Cut Pro, and decided to be a video editor. Then I got MCSE certified and decided to be a sysadmin. Then I started writing website copy and got into marketing for 5 or 6 years. Then I decided to try to learn to program and here we are. I defy anyone to look at that and determine a pattern that could tell me what I should do next.

So no, none of us know where we are in 5 years. But what you do want is a platform. You want to have a set of internally-consistent values that, when followed, add up to the kind of person you want to be, doing the kind of things that make you happy.

Maybe, at your age, all you can hope for is to have lots of different experiences so you can observe yourself in lots of different situations to learn the things that excite and motivate you. I don’t know what that translates to when some douchebag asks where you see yourself in 5 years, but that question is dumb.

The only thing I know for sure is that 5 years from now there’s basically no chance I’m working for someone else. And I know I like helping other people understand their own capability. And I like building things. And I like technology. So advancing those things help me build my platform. At some point in the future, these things will converge in surprising and unforeseeable ways.

3. The role education plays in your career and future opportunities

I am SO the wrong guy to trust on this topic, but here are my thoughts. I dropped out of community college. It has closed the door on exactly zero things I want to do with my life. YMMV.

I work for a CEO who wants to only hire CS-grad developers. If you want to do hardcore shit, a CS degree is often the first hurdle hiring managers will set up. But here I am, college dropout, contributing alongside my CS-educated teammates. I’ve not run into a situation where someone has said “you have all the right experience, if only you had a degree”, while grads actually are likely to hear the opposite from time to time.

If I need to tell you why a bubble sort is inefficient or implement a binary tree search algorithm, I’ll just keep borrowing that knowledge from people who paid good money to go get it.

I’ve got a real problem with formal education in today’s world, and I’m sad to say that when it does matter, it’s about the piece of paper. Schools are no longer the institutions that push the boundaries of what is possible (they can no longer keep up)… that’s going to happen at your workplace.

Here’s what’s crazy to me: You’re becoming book-smart at school and street-smart on your own time. How in the world does that not make you completely unstoppable? (Hint: it does make you completely unstoppable).

4. The type of culture to select for

The underlying question is: how “you” can you be? You’re always going to deal with cultural values that don’t match your own in various degrees, but my time at my last employer felt extremely constrictive in that regard. It was like wearing a cultural straitjacket.

And you know what? It was totally fine. Glad for the experience. Wouldn’t do it again, but I have no regrets.

But developers are a lucky bunch, and get to pick the kind of places they want to work. You’ll soon be in a position to say “no” to a lot of places, and I’d recommend you evaluate culture on this alone: How comfortable are you being exactly yourself in this space? There’s stuff you value and do automatically, is it rewarded here? Or do you have to sort of pretend to be something you’re not?

5. Building your mentorship

I’ve received a bunch of advice by asking one-off questions at local meetups. But it all pales in comparison to that first couple of jobs. You don’t have to announce that you need a mentor. You’ll just work with smart people and steal fire from the gods.

With dedication and patience, this will provide a mentorship to you that will rival anything you could have done by taking one of these bootcamp-style “become a developer” programs.

It’s up to you to stitch it together, but you’re doing all the right stuff.

6. Practice shipping

When I was just getting started, I felt like I had to know everything about everything, so I could ship something impressive. This is ego and it is folly.

I remember a meetup where a new developer demoed his first public work, and I had to stifle a chuckle, it was so naively built, simple, and unattractive. And then I bit my lip in shame when everyone heaped praise on him, because he showed up and shipped software.

If you don’t yet have all the skills you need to ship your idea, you’re thinking too big. Start smaller. Don’t worry about the design. Don’t worry about doing it perfectly. Don’t worry that it’s unoriginal, elementary, or even embarrassing.

You’re on the second rewrite of your sample app? Did the first one work at all? Ship it. Did it almost work but not quite? Ship it. Was it ugly? Ship it. Untested? Ship it. “If it doesn’t embarrass you, you shipped too late.”

That lesson, the ability to let go of perfection and get something into the world, scales up as you become more broadly skilled. Learning that is vastly more important than learning proper CSS technique or TDD. True story.

7. College degrees are not for job applications

I very, very rarely offer blanket-statement advice to people. But here is some: you should go to college to learn and do the things that fascinate you. Period.

As time marches on, when it’s time to wave your piece of paper in front of someone, it matters less and less what that paper is for. Most of my favorite developers are former designers and writers. These are people who approach code from a variety of philosophical angles, rather than a predetermined set of problems that need the right algorithm to be solved.

You’re obviously a sharp written communicator, and that bodes well for you as a developer, as they’re strikingly similar pursuits in many ways. More importantly, communication skills open doors for you in areas of software that are typically closed to engineers who prefer to let their code do all the talking for them.

College is not the networking opportunity that it once was. That’s all extracurricular now due to meetups, groups, Twitter, etc. If CS continues to fascinate you, go crazy, but if you’d rather go into the humanities, philosophy, accounting, whatever, please do what your heart dictates and don’t put your as-yet-undecided career goals in the driver’s seat.

Lastly, a note about tailoring your degree to get jobs:

HR people post jobs. HR is a relic. HR is a joke. HR speaks buzzwords, degrees, and checks off boxes. Prerequisites like years of experience, technology-specific requirements, and even college degree requirements are a lie.

You’ll get damn few jobs through the traditional Apply => HR Screen => Interview process. Maybe your first couple. But it’ll snowball from there and it’ll all be your existing body of work and your reputation, until the only people that hire you are people that want just exactly you in a role that they know will suit you perfectly. So it’s pretty shortsighted to tailor your expensive, multi-year, potentially mind-expanding educational experience to please some resume-shuffling HR rep at one or two companies you’ll only be at for a year.

8. Switching jobs

I think a given developer is 6-12 months from being proficient in any language/framework of their choosing. Don’t let 5-to-10-year veterans intimidate you: many of them have had the same year of experience, 5-10 times.

In fact to prevent this, you should plan right now to switch jobs frequently (every 18 months or so), at least at first. You’ll watch your experience diversify and your pay jump up ferociously. (But don’t get addicted to the money… it levels off after that and studies show over $75K actually decreases happiness.)

So in essence: Ignore money, and pick the place with smart, helpful coworkers and a technology stack that you want to develop your skills in.

A note on self-effacing honesty:

What people refer to as “honesty” or “humility” in your cover letter (and your telling people in no uncertain terms that you’re “junior” in need of “mentoring”) is actually pessimism. Pessimism is a precursor to depression. Many of my bouts of depression can be directly traced back to prolonged moments of pessimism, masked as “honesty”. Go buy the book Learned Optimism. Seriously. Do it now. The book won’t solve all your problems, but it will open your mind to the idea that you have the ability to change these thinking patterns.

This self-effacing form of pessimism is one of my big downfalls, even up to this very day and minute. If you want to get a 10-year jump on me, start projecting an undeserved air of confidence, because you deserve it more than you currently know.

This advice is for me as much as it is for you: Stop apologizing for what you don’t yet know, and take some damn credit for being bright and hardworking enough to know it in the future.

I’d suggest trying to load that into your brain and taking another crack at your cover letter. You’re a startlingly bright dude, and I’m delighted that you don’t yet see your absolutely limitless potential, because I’ll get to steal some credit when you’re a big famous programmer.

There’s a lot more I’m sure I could say, but I’m too tired to think straight right now. I’m glad to know you and excited for your prospects.

To him, these choices were life-altering. Choosing one job over another, being rejected by potential employers, pursuing higher education… all these seem like life-or-death situations in the moment, but with the benefit of time & an external perspective, a person can relax about most of it.

This person I barely knew at the time is now one of my closest friends, and I think the advice was helpful. With the benefit of 18 months of additional hindsight, I’ll doubly endorse the words above for any aspiring or new software developer.

If you’re looking to break into software, hit me up here or on Twitter, I’m curious to gather people’s experiences and questions for a proper blog post in the future.

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.

Benji’s priority box

Last week, I lost a close friend to cancer. Benji Edmund was the best of us: Kind, cheerful, inclusive, and irrepressible.

He was a nerd of nerds: he fully owned and embraced the things that made him different, and did them better than most of us. He also embraced the things that made others different, and brought people together from every area. It was no surprise to me to see a huge group of people at his funeral, each touched by him in some way.

All this week, I’ve really resisted the urge to analyze his life and try to draw lessons from it, because I mostly just want to be sad and hurt, to wallow in the unfairness of losing him.

But after seeing his family and friends selflessly share what they learned from him, I feel compelled to point out some of the ways Benji was so special to me.

Living without regret

It’d take much more than a single blog post to describe the ways he inspired and influenced me, so I’ll focus on one or two things that are on my heart.

At his funeral, people shared what they admired about Benji, things I thought perhaps only I’d noticed. He had a genuine confidence that came not from lack of fear, but from understanding that he could accomplish anything if he simply never gave up. In the 8 years I’ve known him, I’ve never, ever seen him give up or back down from an intimidating task.

What struck me most, though, was that after he learned that the treatments weren’t working, he looked at his life and declared he was happy with the result. He said he was proud of his family, proud of his career, proud of his hobbies, and wished only that he’d had more time to keep doing what he’d been doing.

How many of us can say that? How many of us are so contented that if the worst happened, we could say we lived without regret?

Benji’s priorities

His peace of mind was no accident. Ultimately, Benji’s greatest tool in living a happy, fulfilled life was his perfectly clear set of priorities, and his rigor in defending them.

Benji’s family always came first. He was like a superdad. Being present for his family was never a question, and there was never any doubt that his wife Heidi and kids came first. He didn’t wear a badge saying this, and never uttered the phrase “my family comes first”, but everyone knew where he stood.

Although Benji’s work took a permanent backseat to his family, he always rose to the top and excelled at every career turn. He always managed to pick a professional challenge that was just outside his grasp, and was willing to leap from a place of comfort, trusting that he’d somehow make it to the other side. He took genuine joy in his work, and everyone that worked with him remembers him as the “glue” that united everyone. At a relatively young age, he became highly sought after for anything ops and devops related.

Benji’s hobbies were equally impressive. If he was into it, he was really into it. He also seemed to prefer hobbies that he could share with other people. Video games, brewing beer, movies, music… he was never content to keep them to himself. He preferred relationships and experiences to “stuff”, trotting the globe with friends and family while still driving his same busted old Ford Focus the entire time I knew him.

Defending his priorities

It’s not enough to know your priorities, you have to defend them. And Benji defended his vigorously.

Benji’s family-first philosophy, to the 25-year-old version of me, seemed weird. He would frequently turn down offers to go hang out, he wanted to go straight home to his wife (and later, his kids). If we wanted to do something, we were welcome to come over and spend time with his family.

At the time this was hard to understand. But with hindsight, it was a master class in understanding and defending your priorities.

Benji’s boss, the CEO of Instructure, spoke at his funeral and told his story of recruiting Benji. It took months, because he absolutely would not jump over to this new startup until they had health and life insurance benefits buttoned up. He simply would not make that sacrifice. I’m sure this seemed inconvenient or even odd to the team there.

But for Benji, this was a simple decision, because he took his priority list, put a family requirement up against a work requirement, and knew which one would win.

Shaking the box

Clay Christensen, in How Will You Measure Your Life, talks about understanding long-term vs. short-term gains in your personal life. The benefits from sacrifices on behalf of your family can take years or even decades to come to fruition. Work and other pressures can offer immediate benefit and immediate consequence.

So when it’s time to look at our priorities, we often sacrifice these long term benefits for our family, knowing they will understand. Instead, we often choose short term gains to placate the people who won’t understand (a boss, for example).

I imagine priorities like this: imagine writing every thing that is important to you on a slip of paper. You probably have a sense of their order, and after ordering them, they go into a box.

However, there are 2 unavoidable challenges for your priority box. First, over the course of time, more things will become important to you, and you’ll start adding more slips of paper. Second, at random intervals, life will come and shake up your box. You can’t prevent this, nor can you predict when it will happen.

So the construction of this box is of utmost importance. But most of us just leave it the way it is, a simple box containing all the stuff we care about, and the thing that seems most important at any given time is plucked out and given our time and attention.

What was different about Benji’s priority box

Benji, however, built compartments into his box, keeping his priorities from being mixed up. Benji took great care with the construction of his box. He recognized it for what it was: the container for all that he cherishes and the only tool he has to protect his most limited resource: his time.

So yes, more pieces of paper were slipped in, and life came and shook his box with all its might. But Benji never had any doubts about which activities got the bulk of his time and attention, because they rested in their appropriate compartments.

It’s shocking to me that Benji understood his long-term priorities at such a young age. He’d set up his hierarchy pretty much by the time he’d graduated high school. He married his high school sweetheart, placed her at the top of his list, and never, ever took her (or the rest of his family) down.

I can say with some confidence that this was Benji’s formula for a regret-free existence.

I’m not proud of my priority box (yet)

My box is shoddily constructed at the moment. I have a lot of mixed-up priorities, coming in faster than I can handle them, and little sense of how to put them in order. But I now have a model to follow for choosing how to build my compartments and protect the things that I cherish the most.

I can’t express in words how broken my heart is right now. My heart hurts for my loss, for the pain his family is in, the long road they have ahead, for the loss the world experienced by losing him. But I can take a small measure of comfort in knowing that Benji truly lived his life, with kindness and on his own terms.

I love you forever, Benji. I miss you terribly. Thank you for reminding me to live and love without regret.

What’s so great about getting things done?

Each of these contains months- or years-old tasks that now exist solely to mock me

One of the fundamental principles of marketing is to sell relief from pain. So it’s no surprise that Getting Things Done has become a perennial phenomenon.

It offers the promise of freedom from the feeling of being buried beneath a task list that grows faster than you can cut it down.

It’s a nearly ubiquitous pain point. We have more things to do than we can keep track of, let ourselves get overwhelmed, and give up before accomplishing our goals.

And for its adherents, GTD seems to deliver. They are finally able to climb up out of their to-do-list deficits, feel less overwhelmed, and regain a sense of control over their work.

As for me, I could never finish the book. Maybe it’s the corporate-speak delivery, or more likely my own life situation, but I just can’t seem to get into it. I have studied it through vicarious means, via podcasts, cheat sheets, tutorials, etc.

Organizational systems are overrated. There, I said it.

Every organizational tool, system, or book I have tried has either failed me or I have failed it. The tools on paper, computer, and smartphone I’ve used comprise an elephant graveyard of dashed hopes.

My track record over the past 15 years proves this out, from Franklin Planners, to notepads, to desktop software, to writing my own pomodoro-based todo web app, to GTD, only to expose my own lack of discipline by giving up and going back to my old ways.

I ran through the OmniFocus tutorials and implemented the whole system: setting up contexts, projects, assigning next actions, toggling context based on my location, and it all seemed great, but it just didn’t click for me. I just couldn’t get emotionally invested in the reward cycle for accomplishing stuff past a month or two in GTD or any other system.

And yet, my life is not an aimless train wreck of unaccomplished goals. So what gives?

I’m a bit concerned about the “things” part of GTD.

I’ve now spent the last several months doing nothing but getting things done. Tasks checked, issues closed, code written, yaks shaved, and I’m pretty proud of what I accomplished in that time.

But for all the stimulation I got from this time of hyper-productivity, I’ve also created a tremendous emotional debt by ignoring friends and family, and have been blind to other opportunities in my life. I’ve managed to become so dependent on the mental “cookie” I’m awarded for productivity that I’ve forgotten to be present for the rest of my life.

It’s ironic that many of the most important activities in our life don’t seem to fit in our todo list backlogs. Things like truly listening to a friend, helping out with the dishes, or taking time to build a lego fortress with your kiddo don’t stack up against “call Janet to get forecast numbers for Q3”

Short-term vs. long-term optimization

Life is about a lot more than the buzz we get from short-term accomplishment, yet we tend to torture ourselves over leaving near-term tasks unchecked. Or, we pat ourselves on the back for all the things we accomplish within a given workday, not realizing the decades-long effects of what we’re ignoring in favor of these near-term goals.

Clay Christensen explains better than I could about this optimization for “near term” versus the “long term” (check out the video at the end of this post).

Achievement = purpose + effort

I believe people are capable of profound productivity when driven by a sense of purpose and desire. For me, when I’m in “purpose mode”, things are crystal clear, and I’ll plow through uncertainty and obstacles to accomplish something. But often in my work, I shuffle around and pick at things without feeling like I am making progress.

To me, GTD is too often about trying to reduce the amount of perceived effort to accomplish things we don’t necessarily care about. I can take these things I’m shuffling around, apply GTD, and suddenly have a plan of action to accomplish this thing I don’t feel like doing.

But long-term, meaningful achievement means directing your effort to things that are truly connected to your own sense of purpose.

For me, the solution has been to figure out how to go back to the root and care about what I’m doing. Sometimes that means crumpling up the work I’ve done on things I don’t care about to start from scratch on something I do.

Overcoming overwhelm (without neat little boxes)

But what about that sense of being overwhelmed that GTD solves? In my experience, GTD’s main benefit is that it helps you make a perspective shift: moving your view of things to be done from a vertical wall (now) to a horizontal path (over time).

It’s not easy, and it’ll have to remain a subject for a future article. But suffice it to say, I don’t believe it requires the implementation of a “life management system” to achieve this perspective shift.

How about “Getting Thing Done”?

Maybe instead of beating ourselves over the head daily with all the things we *must* do, we should pick up one, exactly one, thing we would like to have done or have made meaningful progress toward by the end of the day.

I have tried this pattern in my life, each time to a surprising amount of success. A lot of the meta-stuff will take care of itself (checking email, responding to calls, getting my oil changed, etc.), but allowing myself to focus on only one significant accomplishment a day actually causes me to get more done in the course of weeks/months than when I’m trying to check off properly-broken-out tasks all day.

Some friends of mine (I found out, coincidentally, after writing several drafts of this article) are creating a new iPhone app, tentatively called One Thing. It won’t be ready for a little while, but it certainly sounds like a better fit for me than tools that promise to become a wellspring of focus, until they become a stagnant pool of tasks begging for my attention.

I can’t quit you, ubiquitous capture

One component of GTD will stick with me for the rest of my life: I love ubiquitously capturing thoughts, desires, goals, and fragments of information in tools like Evernote. It’s just the “getting things done” component of GTD that didn’t work for me.

Not that writing todo lists is useless! I do think that writing down all the important stuff you need to get done is a good exercise. Then, a few years later, go back and look at it, and have a good laugh at all the things that seemed so blasted important at that moment in time.

Lastly, please watch this video of Clay Christensen speak about living a life of purpose by moving our focus beyond the near term.

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

LivingSocial, knowing your business, and gloating

Yes, LivingSocial is imploding. Yes, we saw it coming. Yes, we knew that the multi-billion-dollar valuation was silly and to be short-lived.

It’s easy to be snarky. And fun! I get a laugh from my friends, I get to show how smart I am for having “seen it a mile away”, all from the comfort of my armchair, having taken no risk.

But when I participate in such snark, I also feel a bit hollow inside. Because I know people, human beings, work there. Hell, I know people who work there. And sarcasm and snark only pile on insult for these (typically) innocent people.

And an additional danger: flippant, snarky responses are rooted in an “I was right” mindset, preventing us from learning anything more. But there is always more to learn.

My daily deal near-miss

A few years ago, I helped create a startup with some pretty audacious (and ultimately insane) goals. Things weren’t panning out with the original, mathematically-impossible business model, and we discussed “pivoting” into the daily deals space.

It was around then that my pre-arranged 3-month contract came up, and although I received some pressure to stay, I made the decision to leave, while my friends stayed behind. And their daily deal business started to catch fire.

I watched their office jump from 3 to 5 to 10 to 50-plus employees. I still held a significant stake in the company and wanted to see them succeed, but something about this rate of expansion concerned me. In fact, a friend of mine worked there for exactly one day before the environment creeped him out to the core and he quit.

My friends told me that the company had to expand quickly, that everyone in the daily deals space was growing more quickly than was sustainable, because only the largest survive, while the smaller firms would wither and die. (Interestingly, the opposite seems to have happened.)

Their work environment disintegrated as the pressure ratcheted up, paychecks started bouncing, and the entire thing became a news-worthy fiasco. I was comfortably off in another position elsewhere, but it still broke my heart to see my friends suffer (and to toss yet another worthless stock grant into the shredder).

Don’t let bad business models catch you by surprise

One lesson in this is simple: Take the time to analyze the business model of the companies you choose to work with. Do they make money? From whom? Who benefits? Look at the founders. Are there happy customers in their wake, or a string of disappointed people?

Do a gut check. Does it feel right, or does it feel like you’re selling out a little? You know, that feeling when you put that thing you want, but don’t need, on a credit card? The trading of the long-term consequences for an immediate thrill?

If you get that second feeling, stop. Weigh it more carefully. You may not change the decision, but your reasons need to be much more clear, or you’re creating a recipe for regret.

Being right is not a license to gloat

The other lesson is for us spectators: Maybe let’s stow the sarcasm on this one. For a lot of people, LivingSocial’s (likely) collapse is going to be very personal and very painful, so please take a moment to remember that before dancing on its grave at the expense of human beings who are hurting.

Dumb stuff we say to non-programmers

Nearly fifteen years ago, I left my home to serve a two-year Mormon mission in Minnesota and Wisconsin. But one does not simply walk into the “mission field”. They must first spend three weeks at the LDS Missionary Training Center in Provo, Utah, which is probably best known for its unlimited supply of Marshmallow Mateys.

In the sixteen-hour-a-day crash course of the “MTC”, one major recurring theme was on using language that is familiar to the listener, rather than Mormon terms and colloquialisms.

In fact, it’s quite easy to spot members of the LDS church that have had this training, as they tend to use terms such as “congregation” (in the LDS church, this is referred to as a “ward”), “lay minister” (“Bishop” in Mormon parlance), or “church responsibility” (known as a “calling”).

There are scores, if not hundreds, of such “insider” terms woven into Mormon culture.  Imagine my disappointment after joining the church at age 11, upon discovering that not only was there to be no steak at steak conference, but also that stake conference was a two-hour-long marathon of back-to-back sermons.

The LDS church knows what many of its members do not: that the language you use has the power to invite people to participate or to shut them out.

There’s no “PTC”

Programming has a much larger, much more deeply embedded intrinsic language, except there’s no Programmer Training Center where ambassadors from the world of programming are taught this essential principle. Perhaps there should be.

One of my regrets is that at a prior company I never got to hold a training session I’d planned for our development team, where our accountants would come talk to them in tax code, to convey a sense of what developers often sound like to their coworkers.

It’s not that insider language is bad. It’s quite necessary. The fact that police communicate urgent information via short, numeric codes actually saves lives. For the rest of us, our jargon provides invaluable shortcuts when discussing complex concepts within a group that has a shared background and a similar level of understanding. Developers, in their efficiency, cram oodles of meaning into words and phrases that sound like total nonsense to non-technical folks.

But even knowing this, I often catch myself spouting jargon and terminology that draws blank stares from less-technical people around me.

Terms that shut out non-programmers

It’s hard to keep in mind that you’ve accumulated your vocabulary over years, or even decades, and that people around you may not share that same type or level of experience.

But even more difficult is the mindset change that requires modifying, defining, or even skipping terminology to accommodate people that don’t share your technical background. Here are some terms that triggered a sense of being “locked out” of programming conversations or intimidated me as a new programmer:

  • Algorithm: That word’s pretty big for its britches, considering it just means “a solution” or “a way to get to a solution”.
  • Abstraction: It’s a great term for programmers, but “stepping up/back a level” may suffice for non-technical folks.
  • Interface: Another fancy way to say “the way two things talk”
  • Parse/parsing: Another great term that is tough to unpack. The closest I can define is “to digest”.
  • Boolean: It’s just true/false, except when it means something completely different.
  • Design patterns: I don’t know how the Gang of Four did it, but they somehow created a naming strategy that is 100% guaranteed to make a non-programmer’s eyes glaze over.*
  • Parts of your technology stack: Unless for some reason you need to explain a technology, its purpose, and its benefits and drawbacks, it’s not helpful to let non-programmers know you’re going to create a Git topic branch to migrate your denormalized serialized data to a REST-based document database while preserving your Solr indexes.

Those are just a few of many, many terms that can sound odd or intimidating to people. Even terms like “array”, “hash”, or “object”, which to programmers is like “flour”, “sugar”, or “eggs”, are an alien language to 99.9% of people.

Now, if you’re a developer, you may look at that list of terms that intimidated me and wonder why I didn’t just “get over myself”. I can assure you that most people, when confronted with unfamiliar language, are silently wishing for you to speak at their level (or worse, misinterpreting you or tuning you out entirely).

The danger zone: misunderstood terms

I could devote a whole, hilarious post to programmer jargon that non-programmers think they undersand (and before I was a programmer, I was sooo that guy). The danger here is that instead of tuning out, people may get a completely incorrect picture (think “steak conference”).

  • API: For a thing that basically means “how you talk to my software”, this is frequently misunderstood.
  • AJAX: I used to think this meant any interactivity on web pages. In all likelihood, so does your CEO.
  • Object-oriented: I literally once told someone I was pretty sure it meant programming directly with graphical objects, you know, like buttons and stuff.
  • Technical debt: This is too often used as “parts of the code I don’t like” rather than “remnants of the best way we knew how to solve problems at the time”. So nontechnical decision-makers often discount the entire concept.
  • Refactoring: To you, it may mean “We’re paying down some of this high-interest debt.” To a stakeholder it means “I won’t get anything that I want while the developers play in a sandbox.”
  • Scalable: To me, this means “able to handle occasional traffic spikes” while a stakeholder thinks it means “racks and racks of stock-photo-style servers, ready and waiting for our inevitable million users.”

In my opinion, these terms are fine, with the only trick being to make sure you toss in your definition to check that you have a shared understanding.

My favorite programming metaphors

There are some programmer colloquialisms that I will never apologize for. And in fact, each time I explain them to non-programmers, they’re grateful for having them in their lexical toolbelt. They’re also great because each tells a specific story:

  • Yak shaving
  • Cargo culting
  • Bike shedding

If you’re not familiar with all of them (or even if you are), Matt Nielsen has written a terrific, laugh-out-loud funny post defining all three.

A path forward

Developers can’t even agree on the definition of terms among themselves, so what hope have we for a shared understanding with our non-technical cohorts? Well, like all language, it matters less what the terms mean and more what the shared understanding is of the people who are communicating.

Half of the solution can be handled by good process, and half is deeply personal.

Solution part 1: Shared definitions

Extreme Programming (guitar solo squeeedleedeedleedeee!) predates my career by a wide margin. But I love the concept of the “Metaphor” principle, which is similar to the “ubiquitous language” principle in domain-driven design, which advocates for a shared set of metaphors and language between the stakeholders (the problem definers) and the developers (the problem solvers).

I also think that non-developers and new developers are more than willing to meet somewhere in the middle. Stakeholders are quite happy to pick up technical terms when they’re core parts of the business or when they save time.

In my experience, the best results come from starting to reach out and show an interest in a business domain’s language, then slowly walking folks toward the technical implementations, bit by bit.

Solution part 2: Conversational empathy

The other half is in developing a specific kind of empathy: learning to have a running thought that wonders, “How are the things that I’m saying coming across to this person?” In doing so, you are forced to think from the perspective of the other person, to imagine what they hope to get from the conversation, and to think about what you’re saying that might trip them up.

This is a personal struggle for me, as I delight in finding just the right word  to describe something, a habit that often irritates people with my ostentatious loquacity five-dollar-word jibber-jabberin’.

But I really do believe that by adding one extra layer of thought during conversations, and periodically sitting down with stakeholders to nail down business-domain terminology, a developer can become as effective a force for good as anyone in the organization.

*I want to come up with design patterns with awesome names. The Sandwich pattern. The Exploder pattern. The Hug pattern. Who’s with me?

“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.

Addendum:

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.

Ruby DCamp: What I learned on summer vacation

Ruby DCamp is one of only a couple of my “can’t-miss” events of the year. This was my second time participating, and both times, I’ve come home with life-changing experiences. It’s incredibly special to me, and I want to share with you some of the reasons why.

What is Ruby DCamp, and what makes it so special?

Ruby DCamp is a code retreat and unconference (which I’ll describe later), and takes place about 45 minutes out of Washington D.C., in Virginia’s Prince William Forest state park.

It’s the brainchild of Evan Light, a Maryland-based Ruby developer and self-described hippie. It’s simple in concept: a three-day event, held in the forest, for programmers of all skill levels to get together, write code, socialize, and self-organize as a community.

What makes DCamp unlike most other events is a combination of the venue, the sessions, the community, and the event’s mission.

The venue

Unlike any other conference I’m aware of, DCamp takes place at a campground, the sort of idyllic summer camp depicted in movies and TV shows from the 1980’s and 90’s.

There’s no internet: it’s BYOWifi, and cell coverage is… meh. A lot of people (like me) don’t have tethering and have to borrow someone else’s device to connect.

The cabins are subdivided into rooms, with 2-4 cots per room. So there are some limitations on privacy and personal space.

The constraints imposed by the remote location, close quarters, and lack of connectivity are actually incredibly freeing. Without all the little caves we tend to retreat into, we’re encouraged to bump into one another, strike up conversations, and let serendipity happen.

Attendees wake up early, stumble into the bathrooms (which are about what you’d expect at a campground), and are ready for breakfast around 8. The conference proper starts at 9, breaks for lunch, and wraps at 6 each day.

The Format, Day 1: Code Retreat

Day 1 is a Code Retreat, which is a well-defined formula for honing programming skills. At DCamp, you pair up, work on solving Conway’s Game of Life for 45 minutes, follow up with a retrospective, and jump back in with a new pair programmer. Meanwhile, in each iteration, Evan throws a new wrench at you by adding a constraint.

One of the constraints is called “mute evil” pairing, where no speech is allowed, the code does all the talking, and the programmers are instructed to sort of antagonize one another through the code. It was all very challenging, and at times, frustrating.

By the end of Day 1, I was completely wiped out. It’s not my favorite part of DCamp, but in the discomfort there’s a tremendous amount of learning. It’d be quite difficult to spend a full day gaining that much exposure to people of varying skill levels, styles, preferences, and tools without learning a ton.

The Format, Day 2 & 3: Unconference

On Day 2 and 3, the group gets together and pitches each other on ideas for topics for the day. Then, you write down your proposed session and duct tape it to the wall.

Each member gets 5 votes. You cast your votes by dotting the duct-taped papers, they’re tallied, and Evan compiles it into a two-track schedule.

The schedule tends to fall into two tracks: one is code-oriented, and the other tends toward the philosophical.

Each track gathers at an end of the main cabin, and you’re free to “vote with your feet” and switch between tracks, spin off a session of your own, or just duck into your cabin for a nap. Or help out in the kitchen (more on that in a bit).

There’s also a third track for new Rubyists or non-programmers, held out on the picnic tables outside. For such a small group, it’s shocking how accommodating the schedule is for varying experience levels and interests. That’s the benefit of having the attendees determine the schedule, I suppose.

As for the sessions themselves, I’ll provide a “what I learned” section toward the end.

The Community

DCamp is essentially a self-organizing pop-up community. There’s no staff to speak of. Evan handles the logistics of making it happen, but once the camp starts, all sessions, planning, cooking, cleaning, and activities are the shared responsibility of the participants.

Some of the people there are well known in the community, and some are first-time programmers. But everyone pitches in, everyone teaches, everyone learns, and everyone enjoys each other’s company.

After dinner, it’s up to participants how they spend their time. Some retreat and read books, many bring card and board games, some hack on projects, and some just converse (you may not be surprised that I tend toward the latter).

I can’t overstate the quality of humans that DCamp attracts. It’s an awe-inspiring group of people. I’m still astonished at the backgrounds, knowledge, accomplishments, and depth of character of the people there. I actually feel a bit sad knowing that I don’t get to interact with many of them at that level more than once a year.

I got to hang out, code, and talk with some personal heroes of mine. I also met people who became new personal heroes to me.

The Food

It may seem strange to spend a section on the food, but DCamp has become known for taking food seriously: There are options for everyone from vegans to paleo adherents. Rather than burgers and hot dogs (as had been the case in prior years), the menu consists of a number of from-scratch items made in the dated, somewhat dangerous, but still-functioning industrial kitchen in the main cabin. This year, the food ranged from grilled portabello to a smoked whole pig (yes, seriously).

DCamp eats are also famous for improvisation. Last year, Brad Herrup made astonishingly good bread pudding from leftover hotdog buns, and this year we had to cut ice cream into cubes with knives, as we’d failed to remember an ice cream scoop.

The food in particular is a herculean task, from purchasing, to cooking, to cleaning. The kitchen is a hive of activity literally from dawn to dusk. Everyone gets a chance to participate: I had a couple of nights of dishes, and got my share of injuries while cooking 20 lbs. of pasta.

What I learned

One of my favorite things about returning for a second year was that it has become a yearly moment to reflect. I got to see the progress that my friends had made in the intervening year, and to realize how much of my own progress I’ve made.

Most importantly, I got to ponder on what I’m passionate about and what I want to accomplish by the next time DCamp rolls around.

Several of the sessions stand out in my mind:

Sexism in Programming: Sandi Metz and several other female attendees helped steer this delicate conversation, and the way the men participated made me proud to be a Rubyist. Without resorting to becoming “word police”, we can make the Ruby community a shining star for diversity until we reach 50% parity between men and women.

Raspberry Pi: I brought my Raspberry Pi (the $25 computer) and led a session on what they might be used for and how to get them set up. Even with technical difficulties with the TV, we had it all set up and running the programming language for kids called Scratch within the half hour session. (Later, we set up Ruby and Rails on it. That did not take half an hour.) I’m still terribly excited about the educational implications of this fun, approachable, and inexpensive computing platform.

If Money Weren’t An Issue: Adam Bachman (originally a philosopher and theologian by training) led a brave, deeply resonant conversation about the things we’d do if money weren’t an issue, or if failure weren’t an option. Pausing to think and openly discuss what we really want to be doing with our lives is not something I’d expected to participate in, but I’m so glad I did.

JRuby with Hiro Asahi: I learned more about JRuby, having used it for work in the past, but I was more struck with Hiro. He’s an example of the best of Ruby’s MINASWAN culture, and I was delighted to learn from him. (MINASWAN, for the uninitiated, stands for Matz [Ruby’s creator] Is Nice And So We Are Nice.)

Visualizing code: Avdi Grimm posed an open question about how programmers visualize concepts in software, and it developed into a rich conversation complete with drawings by people in the group. Sandi Metz showed how she uses Keynote to create a sort of animation to take a complex refactor and explain it to people in a simple, accessible way. I am passionate about using drawings to communicate, and this made me want to really develop those skills.

Spreading the wealth: Another Avdi-led session, he shared how he believes that every software developer can define and create jobs. We may not be a part of the “one percent”, but our responsibility is to share some of the prosperity of software development by looking at parts of our work that can and should be hired out to (real, not virtual) assistants, and start defining new roles and jobs that may not even have been invented yet.

DCamp’s mission

A lot of conferences put together a vision or mission statement. Some craft a nice explanation about how it’s the “conference for people who X”. All of these are great, but DCamp couldn’t possibly do that, because its mission and ideals largely emerge from the community that shows up to participate.

But what makes DCamp so difficult to emulate is that it is very much Evan’s baby. Its soul is found in his gifts, dreams, frailties, and flaws. It simply would not exist without the combination of his love, stubbornness, desire to include and be included, and his deeply-held idealism.

DCamp is Evan’s dream of what utopia might be like, and he cultivates it carefully. And for a few days a year, a few of us get together and sample it. And for two consecutive years, it rang my psyche like a gong.

Thanks to Evan and the attendees for another great DCamp, and I hope to see old and new friends there again next year.

Finding your “sweet spot”

“Brandon, I like you, and you’re doing well, but I’m frankly disappointed. I thought you were going to come in and really set the direction for our enterprise architecture.”

I couldn’t help but get lost in that memory as a close friend shared with me that he was feeling terribly underwater in his work. No matter what he did, he couldn’t seem to measure up to their expectations. It was like he was on a treadmill that was set just a little faster than his fastest pace.

Not long before that, I’d been hired to do a job that I honestly still do not comprehend. Something about diagrams and TOGAF and enterprises. But it sounded fun and important, and promised me an entry point into software development.

As I started on my first day, I was repeatedly told how excited everyone was that I was starting. I was flattered to see that everyone generally regarded me as the person who was there to finally make everything better.

If I’d had a little more experience, I would have recognized this as a massive red flag. Ultimately, as you may guess, those sky-high expectations amounted to a stressful, unpleasant, and yes, disappointing work experience for all involved.

So I could most certainly empathize with my friend. And I shared a simple concept that had helped me come to grips with my own situation.

The diagram

I told my friend to imagine, in one circle, all his desires and abilities. He had enormous capability in a number of areas. He’d essentially run a business by himself for years, managed projects, and led people. He’s also a solid software developer. He has deep marketing talent and a gift for communication.

Then I told him to put all the expectations of this client in a second circle. They were looking for people who could write code. Not just write it, but crank it out quickly and move on to the next thing. So of all his skills, his client only wanted one. The overlap between the two was minuscule. And he felt like he was being run into the ground.

Making up the difference

Even if you’re only using this sliver of your capabilities, you still need to meet the needs and expectations of your employer, client, or customer. So how do you compensate?

You could put in extra hours without telling anyone. You could try and work harder or faster, eschewing all the small niceties in your day that don’t constitute nose-to-the-grindstone labor. Or you could cut corners, and only do just enough to hope to fool them into thinking their expectations are met.

But it’s going to be of little use. There’s no secret extra hours, no corner-cutting, and no amount of focus that you can apply to make up the difference when expectations don’t line up with your goals and capabilities. Ultimately, you’ll either disappoint your customer/client/employer, or burn yourself out trying to keep up.

A better scenario

Have you ever felt really capable? Like a project was not just within your abilities, but right exactly up your alley?

That’s an awesome feeling, and it only happens in these high-overlap situations. When the work that you do aligns with your goals, falls inside your capabilities, and challenges you in the right ways, you’ll be able to completely delight your customer.

You must know your circle

Your side is by far the most important piece of the puzzle, and it’s astonishing how few of us really understand it.

Knowing your circle starts with asking yourself a lot of hard questions: What do I do that makes me “me”? What is it that makes me feel like a superhero? What do I want to accomplish? Who do I like working with? What do I hope to learn?

Understanding their circle

It’s possible that you have an employer or customer that’s as chaotic as a few of mine have been, and you may not even know what their expectations are. If that’s the case, you need to clarify what’s expected of you.

These expectations may seem demanding, things like “we expect you to turn product features around in less than a day”. Or they may sound noble or beneficial to you, e.g. “we see you on a fast track to management, if you’ll only do x”.

All of that is fine, if it lines up with your own circle. The danger is in adopting these expectations for yourself, migrating goals from their circle into your own.

Otherwise, you may find yourself forgetting your own goals and capabilities, and trying to live up to expectations that are not yours. This leads down a path of stress and disappointment.

OK… so what if they don’t line up?

You’ve mapped out your Venn diagram and realize that you have very little overlap between your capabilities/goals and their expectations. What now?

The most important thing is to be honest with yourself about it. But you really only have two choices: to change the situation, or try and change yourself.

Changing your situation can range from easy to very difficult. Changing yourself is essentially impossible, at least in the short term.

You know the person who was “frankly, disappointed” in me? After I’d realigned my expectations with him and that company, I was able to change my situation drastically, without quitting my job, and it turned out to be one of the highlights of my career so far.

You don’t have to quit your job or fire your customer to change your situation. You do, however, have to be direct and honest with the people whose expectations are out of alignment with your own.

And while sometimes that will mean a parting of ways, the wrong strategy would be to suffer silently for fear of losing a job or client that’s making you miserable (and that strategy almost never works anyhow).

The lesson in all this

It’s easy to get mad at yourself for falling short of expectations. But if you step back, you can skip the self-judgment and objectively look at every situation as the fit between what makes you awesome and what people expect of you.

A recurring theme in the things I’ve learned over the years is that it’s futile and agonizing to try to fit into someone else’s model of who you should be. Understand what goes in your circle, and you won’t have to force yourself to “fit” anywhere: you’ll automatically start matching yourself to clients and customers who are looking for all the ways in which you’re amazing.

Depression, digging out, and pursuing happiness

"Whatever the Weather" by monettenriquez via Flickr

First: Defining “feeling depressed” vs. “depression”

This is a sensitive topic, and for a number of reasons, I nearly didn’t publish this post. But I feel like it’s an important subject, so I’m going to proceed, albeit with a couple of caveats.

I define “feeling depressed” as having feelings of sadness or general negativity for a short time. Feeling depressed is a completely natural experience when it follows major events of stress or loss. Having depression generally means you have been experiencing these symptoms for longer than two weeks, and they’re showing no signs of improving. For this article, I’m going to hand-wave a bit and say “depression” to refer to both, short of diagnosed, clinical depression.

If you know or believe you are struggling with clinical depression, do not pass go, declare TL;DR on this post and seek out a professional (or a loved one who’s smart enough to tell you to seek out a professional).

The unspoken epidemic

Depression is a rarely-discussed topic, except among close friends, behind closed doors. Which is sad, because it seems to affect a very large cross-section of developers I’ve talked with, and being able to talk about depression is an important step in dealing with it.

Recently, I’ve made a series of life-changing decisions, the unintended consequences of which triggered a bout of depression that I’ve struggled with over the last few weeks.

And depression is a son of a bitch. It makes things that I can normally deal with easily look impossible. It robs me of the will to do things that make me happy. I feel as if I can’t talk to anyone about it: not my friends, or even my wife, as none of them deserve to be burdened with my problems.

I have felt the effects of true, physiological depression before, the kind that makes you understand why people choose to end their lives. This episode was nowhere near that in severity, but it’d been getting steadily worse for long enough to worry me (and those who care about me).

The “coping bucket”

A friend suggested this metaphor: Everyone has a “coping bucket”, filled with the all-important stuff you use to cope with difficulties. Each time you deal with something difficult, you draw from that bucket. Rest, joy, laughter, etc. help fill the bucket, bit by bit. But when it’s drained, there are no reserves to handle tough situations, and reaching the bottom can be pretty dire. The end of your reserves can feel like the end of the world.

Pessimism can lead to depression

About a year ago, a close friend recommended the book Learned Optimism by Martin Seligman. I think it’s an important book and you should immediately go buy it, but the gist is that pessimistic thoughts are a precursor to depression.

When something bad happens, pessimistic thoughts tell you:

It’s personal: It’s your fault, so take some responsibility.

It’s pervasive: It affects all areas of your life. It must indicate a deeper problem.

It’s permanent: The bad thing lasts forever. There’s nothing you can do about it.

The problem is that in much of modern society, taking credit for good things in your life is considered egotistical (when it is actually optimism) and taking “responsibility” for limitations is considered humility (when it is often pessimism).

So the person who shoulders responsibility for flaws and shrugs off praise is deeply pessimistic, and at extremely high risk for depression. For me and a lot of other developers I know, that may sound familiar.

So when things do go wrong, it’s important to take a minute to stop and look for reasons it’s not personal, pervasive, or permanent.

Examine the environment: It’s not personal

This most recent bout came immediately after I’d drastically changed my environment, and I’d pretty carefully constructed my old one to optimize for happiness. Now, I had brand-new stressors and triggers, but none of the support structure I’d previously had to cope with them.

But instead of realizing this, I immediately internalized – personalized – these feelings. I was sure that these feelings were my own fault, and this line of thinking only served to deepen my depression. But as soon as I realized that external factors were most likely wreaking havoc on my emotional state, I was able to de-personalize the way I was feeling. For me, de-personalizing is the moment I stopped spiraling down and realized there was probably a way out.

Checking environmental factors and changing them is step 1. When you first realize that you’re feeling depressed, a change in scenery is highly recommended. Go spend some time with loved ones. Visit someplace that makes you feel calm. Talk to some friends. This buys time and distance to start thinking long-term.

Changing Actions: Refilling the bucket

After reflecting a bit, I decided to look broadly at the areas of my life and break down the things that make me happy. These are not ideals or even values, they’re observations. They’re leading indicators of my personal happiness, things that tend to precede happy periods of my life.

  • Going on dates with my wife
  • Reading to my kiddo
  • Chatting or going to lunch with my friends
  • Thinking about people I’m grateful for
  • Making something and sharing it
  • Pair programming
  • Writing about things that feel important to me
  • Taking my family to sporting events
  • Going for walks with someone (or by myself)
  • Going to developer conferences and meetups
  • Helping people understand their intrinsic capabilities
  • Educating myself through books & courses
  • Running outdoors
  • Taking time off of work to do things with my family
  • Making people laugh
  • Talking with loved ones
  • Fearing something and then doing it anyway

The thread running through these is that they help reset my perspective. It’s easy to become myopic when confronted with one’s daily battles. Doing the things above help me decouple my sense of self-worth from the wins and losses of daily life.

Avoiding “false positives”

There are some things that, while not necessarily bad, are easy choices that leave little room for the things in the previous list.

  • Staying up late to catch up on my Instapaper or Twitter backlog
  • Watching very good television (The West Wing is my current addiction)
  • Staying late at work to knock out one more solution or have one last conversation
  • Eating whatever I want
  • Worrying about and analyzing the behavior of others
  • Staying up on all the latest news
  • Needing to be “the best” at everything I try
  • Indulging that inertia-based feeling of “I’d rather not, at least not right now”
  • Taking the “safe” route when confronted with risk

I’ll often do the things on the second list when I’m depressed. For others, their second list may include drinking or other activities that act as a temporary distraction from problems. These things seem in the moment like they’ll help you refill the bucket, but often, they actually drain it, with interest.

Reserving judgment: it’s not pervasive

But I have to be careful: beating myself up for dropping the ball and trading away so much of the important stuff is a form of “pervasive” pessimism: the idea that I’m messing up in some areas, so I must not be capable of doing anything right.

The truth is, I’m doing great at some of them, and I’m letting others slip. In order to make this non-pervasive, I had to give myself permission to fail in some areas (or even most areas) without judging myself, and just commit to making small, incremental improvements.

Digging out: it’s not permanent

I’m largely on the other side of this most recent bout. Many of the difficult situations remain, but much of my ability to deal with them has returned. It wasn’t permanent, even though it felt like it might be.

And to me, that’s the biggest problem with depression: is that it feels permanent, and it’s enormously tempting to assume that it is indeed permanent and to just give yourself over to utter despair. I describe it as feeling like I’m stuck at the bottom of a deep well, the light’s so far away you can barely see it, and there’s little hope of climbing out.

But perhaps the most important thing is to realize that this “stuck” feeling is not permanent, that it’s not as deep as you think, and the worst will pass and you’ll again have the strength to climb out.

Growing the bucket

Your actions can refill your “coping bucket”, but changing your thinking can actually grow the size of the bucket.

So to start, I’m going to add more of the things that make me happy to my schedule (and defend it vigoriously), but I’m also going to try to be aware of and re-examine pessimistic thinking.

And most importantly, I’m going to lean on friends and loved ones. It’s because of the advice of one friend in particular that I was able to see a light at the top of this particular well, and I’m enormously grateful.

Again, I need to qualify this with the fact that I am not a psychologist, and that if it’s been a few weeks or longer, you ought to seek out the help of someone who does this professionally. These are just my experiences. I’ve had luck with this strategy so far, and I will keep you posted on how it works out for me long-term.

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?

Sell your principles (not your values)

Money by 401K on Flickr

Not that anyone’s offering, but I want you to know that my principles are available for sale or trade, if the right offer should come along.

It’s important to note that there’s a big difference, in my mind, between principles and values. This difference is subject to no small amount of interpretation, and you may not agree with my definitions, but let’s assume the following to illustrate a point.

Can we call for a definition?

Principles are beliefs based on observation. They are learned. They direct my actions.

Values are core philosophical understandings. They are discovered. They form my identity.

How we get them

Principles are based on experience, and mine seem to evolve at an accelerating pace as I age. I adhere the best I can to the principles I have at the time, but I’ve learned not to get attached to them. Several months ago, I had strong opinions on principles of good software development, but I now find myself taking the opposite position in many areas.

And that’s better than okay, it’s great. Evidence comes across, and your precious principle starts causing you pain, and you start refining your principle. For newer software developers indoctrinated with the idea of TATFT (test all the f****** time), the principle quickly evolves into something that a person can actually live with.

Currently, painful experience has taught me that I don’t want to be caught with any significant functionality in my code that isn’t covered by tests. So I test my code. Most of the f****** time.

That’s a principle. It’s not me, it’s just something I try to do.

Values are different. I’ve discovered my values when I read, hear, or see something that hits my natural frequency. It bangs my psyche like a gong.

When I first truly heard the George Harrison song “Within You Without You”:

“With our love, with our love, we could save the world… If they only knew!”

I pulled over in my car because I couldn’t see. I’d just spontaneously started crying. I still tear up when I hear it. That hit my exact natural frequency. Love can change the world. We can change the world. With love.

That’s a value. That’s me. That’s who I strive to be.

Dying on Principle Hill

There’s a hero fantasy that many of us share about dying for our principles. To use a contrived example: “Did you hear that when Bob was asked to spend Saturday working instead of with his family, he quit? He’s so principled!”

This would be much less likely gossip: “Did you hear that when Sandy was asked to work on a Saturday, she said she would, but needed an extra day next week to spend with her family? She’s so reasonable!”

When we pick a “hill to die on”, it’s often because we’ve mixed up our principles with our values. We can attach so completely to a principle that we wrap it into our identity, which shuts down our ability to reason about that thing.

How can you tell values from principles?

Separating values from principles comes largely with experience. But I don’t think a person gets to carry around very many values. So if you need two (or more) hands to count them, that may be a sign you’re mixing up the two.

It would be difficult, and perhaps impossible, for someone else to bribe, pressure, or convince you to violate your values. Could someone else coerce you into violating it? If so, it’s probably a principle, not a value.

And if you can cite specific examples of how your outlook or your life changed as a result of a realization or discovery, you very well could be talking about a value, and you want to hold fast to those when you find them (again, they’re few and precious).

Sell ’em, trade ’em, just trade up

Someone wants to give you a reward (or a paycheck) to do something that contradicts your principles? Sorry to tell you, it’s not black and white. It may very well be the right thing for you, in that moment, to exchange that principle for the reward you’ll receive.

If you feel a strong sense of conflict between your principles and your work, you’re not selling the principles themselves, you’re selling the right to violate them. This cedes control of them to someone else and breeds resentment.

The good news is that as soon as you assume ownership of your principles, you have the ability to trade or sell them, rather than just selling others the right to violate them. There’s no resentment for treading upon them, and no smug satisfaction for adhering to them, because it’s not you, it’s just something you try your best to do.

I think it’s healthy to learn to happily trade in principles, as long as you’re trading up. It complicates some decision making, as you’re always considering tradeoffs, rather than setting up hard and fast rules in your life and always coloring inside the lines.

Shifting to value-based decisions

Principles, to me, are something like training wheels for decision making. Perhaps the path to enlightenment is to graduate from principles entirely and understand your own values so well that you rely solely on your values as the basis for your decisions.

The first step on this path is to understand that your principles are subject to change, and that when they start causing you pain or conflict, it may be time to consider whether that principle still holds true for that situation. Remember: the principle is not you, it’s just something you try to do.

Lastly, take some time every once in a while to meditate on your values. What hits you like a bolt of lighting? What do you want the totality of your life to amount to? Once you find these, hang on to them, they’re not for sale.

Empathy, circuits, and self-deception

Sometimes in life, with no warning and no obvious desperate need, something comes from out of nowhere and knocks you out of a complacent stupor.

The book

Last year, someone loaned me the book you see to the left. I decided it looked like a good plane read and took it with me to Ruby DCamp. It wasn’t particularly well-written, and was far from a page-turner. But every few pages, it was like banging a gong in my brain:

“Brandon. Wake the heck up. You are acting like a selfish douche.”

Basically, you need to go right now and buy it. It helped me connect the dots on much of human behavior, especially my own, and the ludicrous things we do to avoid having to change our worldview, even just a little bit.

The basic premise is: If you are treating anyone, anywhere, in any way, as if they’re an object instead of a person, you are chipping away at your own psyche by betraying what you know is right. You’ll then manufacture a story, a version of reality that protects you from dealing with this until you lose the ability to connect with others at all.

All of this caught me off guard. I began to realize that I was wantonly wrecking relationships all around me, merely to serve the need to be right and just. I cried hot tears of shame on the flight to think of the way I’d treated strangers, coworkers, even my wife.

My finely-honed skills of justification were leading me to the kind of callousness and under-the-surface anger that I can pretty much guarantee would have ended my marriage. Basically, pretty serious stuff.

There’s a prevalent metaphor in the book about people being “in the box” that I didn’t really latch on to. However, I was struck with the non-intuitive insight that anything you do to help while in this headspace isn’t really helping. It’s like trying to chart a course to the other side of the world if you believe it’s flat. You have to step into another worldview to do anything of any use.

The Circuit

So we have this big, huge problem in our lives. And no ability to solve it by any conventional means.

Guess what the secret is to stepping out of your worldview? To want it. That’s it.

If you decide to truly desire to understand how another person is feeling, you will almost immediately reverse the effects of objectifying another human, and you will begin to put yourself in their shoes.

Unlike almost anything else in life, you can wish empathy into existence.

You then begin to wish the best for this person. You may even wonder what you could do to help this person. You may even find that there is something you can do for this person.

So here’s the thought pattern I saw emerge from this line of thinking:

  1. Judgement/Objectification (or any act of self-betrayal)
  2. Justification (the story we tell)
  3. Realization of the act of self-betrayal
  4. Desire to empathize & correct the action
  5. Re-Humanization of those we objectify (and apology)

That’s a circuit. The goal is to close it as quickly as possible. (In IT parlance, it’s about Mean Time To Resolution, not Mean Time Between Failures.)

Two examples

I’ll give two examples: one from the book, and one from my life.

In the book, on of the first stories is of a husband who’s trying to get some rest, with his sleeping wife beside him. Their baby begins crying, which he tries to ignore. He commits the first act of self-betrayal by not helping. “I’m sure she’ll get up.”

Then the justifications. “Why isn’t she getting up?” “Doesn’t she care that I have work in the morning?” “She obviously is lazy and doesn’t care about my needs.”

So here’s a fully-concocted story that buries anger and resentment inside a person. But if he’d stopped, he could have realized that he she was just his loving wife, that she was sleeping, and perhaps she really needed his help with the baby that evening.

In my own life, I’ve spent decades training all my powers of observation, psychology, and analysis on trying to stitch together someone’s story… so that I can judge them. I still have this nasty habit.

Last week, my wife and I were fortunate enough to travel to Hawaii, and we spent a morning on a cycling excursion with a newly married couple. The young lady had nothing good to say about her trip. She was staying in the most expensive hotel and dining at all the finest restaurants on the island, and found faults in every part of her trip. The bed was too soft to sleep in. The food was disappointing.

I used my skills to project into the future for this couple, and see much trouble for this princess and her pea. And what did I get for my efforts? I got to turn this young lady from a human into a measuring stick that found me superior in every observable way.

But I couldn’t leave it there. My brain is now too aware of the concept of self-betrayal to let me get away with it anymore. I began to realize that here was a young lady that had one chance to have a memorable honeymoon, things kept going wrong for her, and she hadn’t yet gathered the life experience to be grateful for what she had. There might have even been something kind I could have done to help make her trip memorable in a positive way. I stewed over this for a while, apologized to my wife for the negativity, and went back to having a wonderful time.

And that’s just one tiny example of many dozens of acts of self-betrayal I commit on a daily basis.

Closing the circuit faster

Trying to close the circuit can be overwhelming.

You have to forge new neurological pathways, which is always uncomfortable. It requires that you assume that you are not necessarily noble and good and just, which chops your ego into little pieces. Many of us rarely get past Justification. Getting past Realization can seem impossible.

But here’s the amazing thing: if you simply expose yourself to this concept and it rings true for you, it will begin to seep into your thinking. You will no longer be able to enjoy guilt-free judgment of other human beings.

I still have these moments of judgement and anger with my wife, but I now have the gnawing sensation at the back of my mind, the Bat-Signal that tells me I’ve committed an act of self-betrayal. That part is automatic.

Then, I try to see how long it takes me to close the circuit. It still often takes me a day or two to come around, but I’m getting faster in many cases. Eventually, I hope to open and close the circuit so quickly that the net effect is that I no longer sit in judgement over (or objectify) anyone.

What to do next

How many times do I need to tell you? Go get the book! But you can play along at home even if you haven’t read it. The next time you find yourself angry or seething at a person, try to just want to know how they’re feeling. Start telling yourself their story instead of yours, and see where that takes you.

I am a relatively new practitioner of this type of thinking, but I can tell you that it will open your heart to serving others. This will lead you to real friendships, lasting relationships, contentment, happiness, and pretty much every measure of success that will matter to you as you look back on life.

Introspection is a superpower

Note: please pardon the crudeness of these drawings. They were done on an iPad at 2 AM.

What does it mean?

You know what it is to be introspective, right? To be able to analyze your own patterns of thought? A person I admire a lot told me that in his hiring decisions, introspection was the a primary quality he looked for in candidates. I was surprised to hear that, but I think it’s the wisest job requirement I’ve ever heard.

A lot of people see this and conclude that they are largely passengers in life, blown about by the winds of circumstance:

People who see the world this way often have verbal giveaways. “She made me do it.” “He was really pushing my buttons.” “No one listens to me.”

Why give up so much control? Because it’s easy. When life is just reacting to outside forces, we are not responsible for our situation. The boss won’t implement your ideas. Your spouse isn’t supportive enough. You were passed over for a promotion. But it’s not your fault. You’re not responsible for the outcomes, things just happen.

We get the pleasure of being right, but without the burden of having to do anything other than complain when things inevitably go wrong.

Enter introspection.

People who can introspect recognize the fact that their own biases, distortions, and assumptions sit in between actions and consequences, and they have a dramatic influence over our interpretation of reality.

Five people can literally see the same thing and draw five radically different conclusions. The reason is that they each have a complex set of machinery inside their brains that literally alters their reality. How many times have you perceived a slight when there was none? How many times have you been asked “what is that supposed to mean?” when it was supposed to mean exactly what you said? Have you ever remembered something so vividly, only to find out that wasn’t how it happened at all?

Introspection is the work you put in to see your internal machinery for what it is.

What do you do with it?

Being introspective doesn’t necessarily carry any requirement that you act on it, but it makes justifying inaction very difficult.

Here’s an example. Recently, I had an altercation where I got into a tug-of-war with a coworker, and I angrily and passive-aggressively “took my ball and went home”. He was clearly in the wrong. I was right. I was justified. My position was infinitely defensible. Everyone else saw it my way. I won, case closed.

But there it was, gnawing at the back of my mind… what if I wasn’t right? What if I wanted so badly to be right that I was willing to damage relationships to win? (And make no mistake, that’s how it went down.)

Did I apologize? No. Why not? Because shut up, that’s why not. OK, I’m still a bit defensive about it. But the time I took to analyze my actions and position won’t let me get away with this behavior next time. That’s a tiny, broken piece of me that I will fix the next time I encounter a similar situation.

Maybe over time I’ll be able to deal with these situations in real time rather than damaging one relationship to save the next.

The problem is that we all build a thick, protective shell around our internal machinery throughout our lives. It keeps us from getting hurt by what others say or do, but it also inhibits the ability to take in precious lessons or advice. The great thing about having a habit of introspection is that you don’t have to do anything, this shell breaks down, becomes more permeable, and allows lessons to seep in.

Basically, introspection to me isn’t so much the act of introspecting as it is an openness to the lessons all around you, and specifically not closing off when confronted with things that are difficult to hear.

Lots of small epiphanies > one big epiphany

I could tell you 4 or 5 pretty awesome stories of how introspection caused me to shift my thinking in a significant way, but that’s not actually what has had the most major impact on my personal happiness.

The biggest change has been creating the habit of cracking open this machinery to allow me to tinker a little bit, every day. Without much effort, by default I now observe my own behavior and thinking, ask why I did things a certain way, and wonder if it could have been done better.

Just like software developers get used to dealing with hard problems they don’t have answers for, introspective folks get used to challenging their own assumptions and cognitive biases and asking hard questions that may return answers they fear.

What’s the benefit?

Software developers know all about continuous improvement. That’s the whole promise of the Agile movement: small, continuous tweaks based on quick feedback to improve something until it’s shiny and wonderful.

Introspection is the path to an agile life: the ability to frequently refine and improve your interpretation of reality (and your behavior) until you are in a place where happiness is no longer dependent on external sources. And I’d contend that no one ever achieved happiness when it was dependent on external sources.

Introspection also allows you to confront and address the things you fear, to the point where you wonder why you’d ever feared those things in the first place.

Lastly, it’s a prerequisite for true empathy. Once you start asking yourself why you do things, you can’t help but wonder what you would do in someone else’s position. Empathy is a powerful ally (that’ll have to wait for another post), but I don’t believe I’ve met a person in possession of it who lacked the ability to introspect.

So the benefit is lifelong, intrinsic happiness. And mastery over fear. Also the ability to empathize. So, you know, good things.

How do you get it?

You could go become an addict and wake up in a pool of your own vomit. People often take stock of their lives and figure out where they went wrong when they hit “rock bottom”. It also carries with it some downsides… for instance, waking up in a pool of your own vomit. This also generally produces one large, temporary epiphany, rather than establishing a habit of introspection.

You could meditate. I plan to put this into practice in the future, but it’s not how I learned to introspect. I know some people who claim to meditate who aren’t particularly introspective, so it’s not a 1:1 ratio here.

You could ask others hard questions about you. I asked my wife recently if she was disappointed in me for gaining weight after having lost it, and she said “I don’t know… I guess I am.” That’s a hard truth to take in, but you can’t possibly claim to possess true introspection without being open to hard truths.

Hang out with truth-tellers. For my money, hanging out with truth-tellers has had more impact than anything else. Having close friends who are willing to call BS when I’ve deceived myself has precipitated my most painful lessons and greatest personal leaps forward over the past few years.

This is going to sound dumb, but also in this category, I’d put “listen to the Back to Work podcast with Merlin Mann and Dan Benjamin”. They are truth-tellers and you should just start at the beginning and listen to as many as you can stand, until you develop an internal Merlin Mann you can hear cajoling you into being honest with yourself.

Ask “5 whys”. This is a classic problem-solving technique. If you hit pause and analyze your reaction to something, ask why you did it, and why you did the thing that was the reason you did it, etc., you’ll often find it relatively easy to untangle the source and reasons for your own thinking and behavior. This is easy to do (but hard to remember to do) and yields lots of insight.

The temptation is to ask 1 or 2 whys and declare victory over self-ignorance. You’ll typically know when you’ve reached internal bedrock though, because it will be uncomfortable, scary, even painful.

Ask “what if I’m wrong?” When I have something negative to say about someone else and I’m feeling aware and introspective, I try to imagine the scenario that would unfold in the completely impossible event that I’m wrong. What if that guy isn’t a douchebag… what if he’s just trying to live his life like the rest of us? What if this thing that I blindly put faith and energy into is incorrect? This is the hardest to do by a long shot, so consider that the advanced course.

This stuff will change your life

I’m infinitely grateful for the friends and situations that I’ve encountered that have opened up this style of thinking to me. There aren’t many things I can share with people that I can guarantee will change their lives, but helping people trend toward greater introspection is one of them.

If you’ll put some of these into practice I can promise some new kinds of pain as you wince at yourself, but also a new or refreshed ability to take control of your own happiness, and even your life. I’m curious to hear back from you (here or on Twitter) if you have other methods of introspection, other examples, or if you find any of this to differ from your experience.

Learning to Program, Part III: Why you should learn (and why it’s easier than you think)

This is a part of a three-article series on my journey so far as a programmer:

  1. How I learned to program
  2. Programming lessons that changed my life
  3. Why everyone should learn to program (and where to start)

I’ve previously said that the problem with attracting new programmers is not in explaining how to program, it’s in helping people understand why to program.

So why learn to program, aside from the life lessons mentioned in the last post? A lot of reasons, actually.

It really is a form of “digital literacy”. Even if you decide programming isn’t how you’ll make a living, having these skills is like knowing how your car is put together: you will often know how to fix problems yourself, but even when you have to take it to the mechanic, you’re more likely to be taken seriously.

You’ll run a better business. If you have an entrepreneurial bone in your body, learning to program is going to return rewards to you many times over when starting your own company. I’ve seen many startups fail because of poor technical leadership by founders, and many succeed due to good communication between management and engineering.

You’re uniquely set up to succeed. Whether your background is as a writer or a pizza maker, it will likely help bring a completely different perspective to programming, which benefits everyone, including you.

Don’t let your subconscious lie to you

One life-impacting lesson I’ve learned recently from Paul Graham is that we too often let our subconscious make the decision to steer away from things that seem difficult. We mentally file it under “impossible” and let our conscious mind plan our goals around the perceived roadblocks.

Let’s run through some of those:

“But doesn’t programming require a formal education?” No. Next question.

“Isn’t it hard?” Yes. But not in the way you’re thinking. It’s hard in the way that playing an instrument is hard, in that it is merely a matter of practice. In fact, learning to play a musical instrument is the most direct parallel to programming of which I’m aware.

“Isn’t it just for antisocial, nerdy guys?” Oh dear, let’s dive into that one.

First off, it’s time to let go of the programmer stereotype from the 1980s, because it’s not useful and no longer accurate. We have a whole new crop of stereotypes for you to choose from.

Most distressing is the fact that most women have had a lifetime of exposure to the idea that “programming is for boys”, and from a young age, mentally wall that area off. This costs us in software quite dearly, both in sheer numbers and in the diversity of perspective that smart women bring to the activity.

Don’t let a lifetime of people trying to intimidate you (even subconsciously) prevent you from realizing that you have all the capability they do.

Programming is a special ability, akin to a superpower. It transforms you from a consumer into a maker. But it’s not for special people.

Some programmers feel otherwise, that programming is something you need special skills for. Instead of punching them in the face, just remember that a few hundred years ago, these are the types who thought reading and writing should be reserved for clergy. Learn and make all you can, so that these code hipsters can someday complain that they were programming before it went all mainstream.

Starting on your own path

Learning to program isn’t as hard as it sounds if you’re working with people who know how to ramp up the difficulty properly (and speak English instead of jargon). The Learn to Program (Ruby) book I used is a tried-and-true introduction to programming concepts, and I recommend it highly.

Because I evangelize programming to non-programmers, I am often asked, “What language should I learn?” That actually does matter, but mostly because the quality of materials available varies greatly from language to language. This is why I’d say Ruby, Python, or Javascript are great first languages: the quality of instruction materials available for all three is quite good, and they’ll have you actually building things relatively quickly.

There are great resources for new programmers online at Codecademy (Javascript), RubyMonk, and Learn Python the Hard Way. But my personal favorite, by a wide margin, is Hackety Hack (Ruby).

Find the community

Plus, with those languages, there are communities of people who are knowledgeable and generally helpful. There’s simply no substitute for personal, interactive feedback with experienced mentors. Even as a brand-new programmer, I found the pattern of showing up to local Ruby User Groups and following the attendees on Twitter to be incredibly valuable. It helped me create a support network of people who could answer questions or buoy me up when I felt like I was underwater.

Finding a local User Group, following helpful people on Twitter, joining related IRC channels (I use the fantastic IRCCloud service for this), and generally trying to grab the attention of people who do this for a living are all good ways to help luck start to fall in your favor.

Later this year, my understanding is that Mendicant University will be holding classes for newer programmers, and that may be a great time to start. If your local programming groups don’t offer workshops for new programmers, I bet they’d be open to the suggestion.

If you’re interested in learning to program, find me on Twitter and I’ll do my best either to help you or line you up with people who can.

If you knew half of the doors it’d open for you, you’d be starting one of these books or tools tonight and beating down the door of your local programming community leaders to build an initiative for new programmers. If you give learning to code half a chance, I can promise that in some significant way, opening your mind to it will have an impact on the course of your life.