Show How, Don't Tell What - A Management Style

One of the things I’m most excited about working at GitHub is the opportunity to take our time and think through organization and process problems from first principle instead of blindly copying other companies or adopting status quo approaches developed in the last century. We’re beholden to no one except the good people that pay us for our products and that gives us the freedom to build a company optimized for delivering the best experience - whatever it takes.

Last year, as GitHub began to grow rapidly, I was promoted to Director of Engineering. That makes me a manager of sorts. Gross, right? Actually, it’s turned out not to be very horrible at all. Like most things at GitHub, I was given complete control and encouraged and expected to define the role in whatever way made most sense to me. I want to share some of what I’ve come up with.

Don’t tell people what to do

I’ve never actually told anyone what to do here. In fact, I vehemently refuse to tell people what to do. Here are just a couple reasons why:

1. I don’t scale. If I tell someone what to do and they do it, then what? Do I have to tell them another thing to do? What happens when I have to decide what to do for 20 people?

2. Telling people what to do is lazy. Instead, try to convince them with argument. This is how humans interact when there’s no artificial authority structure and it works great. If you can’t convince people through argument then maybe you shouldn’t be doing it.

So if I don’t tell people what to do, then what purpose do I serve and what exactly do I do all day?

I show people how to plan, build, and ship product together.

Essentially, I try to create little mini-managers, each responsible for managing a single person: their self. At first this is mainly about teaching people how to figure out what to work on right now (prioritization). Then it’s more a matter of building their confidence both in themselves and their team to a point where they just do things they know is right without even talking to me (autonomy).

Lead by example as loud as possible

I actually don’t show people how to make decisions and ship product in any real direct way. There’s no How To Ship Product training class or anything like that. Instead, I just do work.

I write down ideas and then market them internally. I ask designers about their comps and concept work. I write code with kick ass docs and tests, sometimes while building out the backend for a feature and sometimes just to clean shit up because it needs it. I deploy responsibly because site stability is job number zero. I soft ship new features and try to get other employees to use them. I write and review blog posts and ship features. I fix bugs. I work with support.

That’s just how you ship software product in 2012.

The only thing that may be unique and interesting about the way I do it is that I insist on being extremely visible throughout the entire process. That means removing sidebar conversations, private meetings, face time, IM, private pairing, and anything else that limits the visibility of work and process.

Just forcing people to be open and electronic where I’m concerned goes a long way in keeping things managed because work at every stage of the product cycle is in everyones face all the time. For one, people tend to self manage when everyone else can see what they’re doing. Also, other people jump in when they notice something amiss. Finally, everyone learns when anyone makes a mistake or does something brilliant.

If a “management style” is something I have, this openness doctrine would be the cornerstone.

Get people contributing

When someone is new to the process at GitHub, I make a concious effort to @mention them on issues, comments, and commits to bring them into a bunch of different projects and discussions.

When they first have an idea or feedback on something, I turn it around on them and use the oldest trick from the open source playbook:

“Where’s your patch?”

In other words, go build the thing in your head, show me how you got there, and then sell it to me and all your peers.

I review their pull requests and try to imagine how they must be perceiving the process, our product, our customers. When I think their perception is off, I say things to correct it. When I think they’re really getting it, I say things to let them know they’re on the right track.

Make everyone a manager

It’s often cited that GitHub doesn’t have managers. In my opinion, a better way to describe the phenomenon would be to say that everyone at GitHub is a manager. Instead of assigning 100% management duties to individuals, the basic role of management is spread between 1.) every single employee, and 2.) a set of custom in-house tools that serve to keep everyone in the know with regards to other projects.

This approach to management has real tangible benefits. Imagine 100% of your “workforce” being able to operate at maximum productivity / efficiency without oversight. The only real requirement for work to be done is for people to be sober (something we’re working on).

Imagine 100% of your “workforce” understanding every part of the product delivery cycle and being able to make critical path decisions on the spot.

Imagine what would happen if 100% of your “workforce” were “decision makers”.

These are my goals right now.

Take a vacation

Today, I start back at work after 10 days on family vacation. This is the first substantial bit of time I’ve had away since I started with GitHub almost three years ago.

Guess how many meetings I scheduled to make sure projects stayed on track while I was away? Zero.

I sent a blanket email the day before I left and asked for last minute concerns. I received a single reply:

Subject: Re: Hawaii
From: Chris Wanstrath <[email protected]>
To: Ryan Tomayko <[email protected]>
Date: Thu, 22 Mar 2012 17:22:20 -0700

On Thu, Mar 22, 2012 at 2:37 PM, Ryan Tomayko <[email protected]> wrote:
> Guys, I'm heading to Hawaii tomorrow. I'll be there for a week and
> plan to be as AFK as possible. If there's anything pressing I owe you
> right now or stuff that'd help in my absence please let me know ASAP
> so I can move it up my list of shit to get done before I peace out.

Have fun.

GitHub had one of its most productive weeks in recent memory. I relaxed and had fun on the beach.

The one downside I’ve found in all this is that I’m apparently extremely dispensable at this point. Shrug. Maybe I should take more vacations.