I have a confession to make.
I sometimes avoid your feedback on the Twitters. It’s nothing personal. I have a saved search for stuff I work on because I want to know what folks have to say. I want to know what problems they might run into or what ideas they have to improve things. Nonetheless, I sometimes just let the unread notifications sit there while I hesitate and cringe at the thought of the vitriol that might be contained within.
I know. I know. That’s terrible. It’s long been conventional wisdom that if you’re going to write software and ship it to other humans, you better develop a thick skin.
Hey, I used to work at Microsoft. People have…strong…opinions about software that Microsoft ships. It’s the type of place you learn to develop a full body callus of a thick skin. So I’m with you.
But even so, when you invest so much of yourself into something you create, it’s hard not to take criticisms personally. The Oatmeal captures this perfectly in this snippet of his brilliant post: Some thoughts on and musing about making things for the web.
That is me right there. I’m not going to stop shipping software so the best thing to do is work harder and develop a thicker skin. Right?
Nope.
I strongly believed this for years, but a single blog post changed my mind. This post didn’t say anything I hadn’t heard before. But it was the experience of the author that somehow clicked and caused me to look at things in a new way. In this case, it was Sam Stephenson’s blog post, You are not your code that did it for me.
In his post, he talks about the rise and fall of his creation, Prototype and how he took its failure personally, and the lesson that he learns as a result.
I have learned that in the open-source world, you are not your code. A critique of your project is not tantamount to a personal attack. An alternative take on the problem your software solves is not hostile or divisive. It is simply the result of a regenerative process, driven by an unending desire to improve the status quo.
This sparked an epiphany. Reinforcing a thick skin detaches me from the people using my software. Even worse, it puts me in an adversarial position towards the folks who just want to get something done with the software. This is so wrong. Rather than work on a developing a thicker skin, I really should work on developing more empathy.
Show of hands. Have any of you ever been frustrated with a piece of software you’re trying to use? Of course you have! Now put your hand down. You look silly raising your hand for no reason.
How did you feel? I know how I’ve felt. Frustrated. Impotent. Stupid. Angry. Perhaps I said a few words I’m not proud of about how I might inflict bodily harm on the author in anatomically impossible ways should we ever meet in a dark alley.
I certainly didn’t mean those words (except in the case of bundled software written by hardware companies. That shit makes me cray!). I was simply lashing out due to my frustrations.
And it hit me.
The angry tweets calling my work “a piece of crap” is written by folks just like me. Rather than harden my stance in opposition to these folks, I need to be on their side!
I need to remove the adversarial mindset and instead share in their frustration as a fellow human who also understands what it’s like to be angry at software. I no longer need to take this criticism personally. This shift in mindset unblocked me from diving right into all that feedback on Twitter. I started replying to folks with something along the lines of “I’m sorry. That does suck. I know it’s frustrating. I’m going to have a word with the idiot who wrote that (namely me)! Email me with details and I’ll work to get it fixed.”
The end result is I’m able to provide much better support for the software.
By doing this, I’ve also noticed a trend. When you sincerely address people’s frustrations, they tend to respond very warmly. Many of them know what it’s like to be criticized as well. People are quick to forgive if they know you care and will work to make it better.
Sure, there will still be moments where I have a knee jerk reaction and maybe lose my temper for a moment. But I think this framework for how to think about feedback will help me do that much less and preserve my sanity. I am definitely not my code. But I am here to help you with it.
As of today, I’ve been a GitHub employee for one year and I gotta tell you…
Please forgive me a brief moment to gush, but I really love this company. I work with a lot of great people. Crazy people for sure, but great. I love them all. Just look at these crazy folks!
I once told a friend that I’ve long had the idea to start a company that would be my ideal work environment.
GitHub is better than that company.
What Makes it Special?
One of my co-workers Rob Sanheim recently reached his seven month anniversary at GitHub and wrote a succinct post that answers this question. And I’m glad for that as it saves me from the trouble of writing a longer more rambling unfocused version of his post.
Rob breaks it down to five key points:
- Great people above all else
- Positive Peer Pressure
- GitHub Hiring
- Culture of Shipping
- Anarchist Structure
Optimize for Happiness
Then again, if I didn’t write a long unfocused rambling post, folks would wonder if they were at the right blog. So I’ll continue with a few more thoughts.
All the points Rob mentioned fall under the overall principle: optimize for happiness. This is not some pie in the sky hippy Kumbaya sing-along around a campfire (though if you’re into that, that’s totally cool). I think of it as a hard-nosed effective business strategy.
You might argue that every company optimizes for happiness in one way or another. But often it’s only the happiness of the owners, founders, shareholders, the executives, or the customers. Sure, we want all these people to be happy too! But not at the cost of employees as it too often happens. Happy employees are more effective and do a better job at making everyone else happy.
For example, as Tom Preston-Werner notes in his Optimizing for Happiness talk:
There are other really great things you can do when you optimize for happiness. You can throw away things like financial projections, hard deadlines, ineffective executives that make investors feel safe, and everything that hinders your employees from building amazing products.
At GitHub we don't have meetings. We don't have set work hours or even work days. We don't keep track of vacation or sick days. We don't have managers or an org chart. We don't have a dress code. We don't have expense account audits or an HR department.
Businesses can be successful when they decide that profit is not their only motivation and treat their employees well (ironically putting them in a good position to make more profits in the long run). Costco is a great example of this.
We’re Not Alone
People ask me if I think having no hierarchy and managers will scale. So far we’re at around 130 employees and we haven’t yet killed each other, so I think it’s promising.
I can understand the skepticism. For most people, a hierarchical management model is the only thing they’ve ever experienced. Fortunately, we’re not the first (and hopefully not the last) to employ this model.
Recently, Valve (makers of Half-Life) published their employee handbook on the web. It’s a delightful read, but the striking thing to me is how similar GitHub’s model is to theirs. In particular this section resonated with me.
Hierarchy is great for maintaining predictability and repeatability. It simplifies planning and makes it easier to control a large group of people from the top down, which is why military organizations rely on it so heavily.
But when you’re an entertainment company that’s spent the last decade going out of its way to recruit the most intelligent, innovative, talented people on Earth, telling them to sit at a desk and do what they’re told obliterates 99 percent of their value.
I think you can replace “an entertainment company” with “a company in a creative industry.” Writing software is a creative process. Your job is not to write the same line of code over and over again. It’s always creating something that’s never existed before.
Ok, so Valve has around 300 employees. But what about a “large” company?
Gore (makers of Gore-Tex) is a company of 8,500 “associates” that works without managers as well. So apparently this model can scale much larger than we are today.
On a Personal Note
I can pinpoint the moment that was the start of this journey to GitHub, I didn’t know it at the time. It was when I watched the RSA Animate video of Dan Pink’s talk on The surprising truth about what really motivates us. Hint: It’s not more money.
That talk profoundly affected me. I started bringing it up at work every chance I could get. Yes, I was the guy that just wouldn’t shut up about it.
As I reflected on it, I realized it’s so common to spend so much effort and time trying to climb that ladder and earn more pay just because it’s there! I stopped to ask myself. Why? At what cost? Why am I using a ladder when I can take the stairs? Am I stretching this ladder metaphor too far? You know, the big questions.
I later read Zach Holman’s series How GitHub Works and realized that GitHub embodies the key principles that Dan Pink mentioned. That inspired me to try and figure out a way I could add value to GitHub. Before long, I started growing these tentacles and joined GitHub.
After a year at GitHub, I’ve noticed is that I’m much less stressed out now, much healthier, and spend a lot more time with the wife and kids than I used to.
A big part of this is due to the family friendly and balanced work environment that GitHub’s approach results in. I still work a lot. After all, I love to code. But I also spend more of my work time actually, you know, working rather than paying “work tax.” Jason Fried of 37 signals has a great TEDx talk entitled Why work doesn’t happen at work.
That's kind of bad. But what's even worse is the thing that managers do most of all, which is call meetings. And meetings are just toxic, terrible, poisonous things during the day at work. We all know this to be true, and you would never see a spontaneous meeting called by employees. It doesn't work that way.
The Year Ahead
I’m really excited to see what the next year has in store for me and GitHub. I’ve had the great pleasure to ship GitHub for Windows with my team and talk about it, along with GitHub, NuGet, and Git, at various conferences. I’ve met so many great people who love what we do, and folks who’s work I admire. It’s been a lot of fun this past year!
I’m looking forward to continuing to ship software and speak at a few conferences here and there on whatever people want to hear in the upcoming year.
Before anyone gets their underparts in a tussle, I’m not trying to say every company should be exactly like GitHub. Or that GitHub is perfect and what we do is right for every person or every company. I’m not making that claim. But I do believe many of these ideas can benefit more software companies than not. Every company is different and your mileage may vary.
But wherever you are, I hope you’re working at a place that values you and provides an environment where you can do great work and be happy and balanced. And if not, think about finding such a place, whether it’s at GitHub or elsewhere.