
What's it like to work at GitHub? - bkeepers
http://opensoul.org/blog/archives/2012/06/05/whats-it-like-to-work-at-github/
======
andrewcooke
"Talented people with a lot of experience have strong opinions."

i hear this often. and i've worked with some people like that, many of whom i
admire (in some ways).

yet i am not at all opinionated (as far as i can tell). when people ask me for
advice, i often find it very hard to guide them because there are so many
options, and what will work best seems to depend so much on non-technical
factors.

and i am not sure what to do about this. i have tried being more opinionated,
and there are times when a decision affected my work and i have _fought_ for
what was right, because i am doing the work. but often other people,
opinionating, just seem like noise (worse, sometimes i suspect people confuse
being opinionated with understanding something).

no real conclusion here, sorry. sometimes i wonder if people are too
opinionated; sometimes i wonder if i am not opinionated enough (or if i am not
that talented - although i do take re-assurance from the d-k effect). but that
part of the post, and a related comment by the author here, disturbed me a
little. i am not sure a place full of opinionated people is that pleasant (or
optimal).

i was wondering if this touches a chord with anyone else?

~~~
cmoylan
"The fundamental cause of the trouble is that in the modern world the stupid
are cocksure while the intelligent are full of doubt." - Bertrand Russell

~~~
andrewcooke
also, "second coming" by yeats, but i am not sure it is true - i have been
lucky enough to work with some very good people, and some of the best were
like this.

as j_baker says, it seems like it's just one of those "life is complicated"
things...

------
albertzeyer
Sounds a bit like Valve. <http://news.ycombinator.com/item?id=3871463>
<http://news.ycombinator.com/item?id=3838880>

Or the free 20% at Google.

I get the feeling that if you have a group of highly talented people around,
it really pays off to give them much freedom.

From the view of the employee, it is also probably a much more motivating,
challenging and interesting setting.

~~~
Deinos
I was about to say the same thing about Valve before I got the comments
section :) Also, very much agree with letting the talented do their thing as
long as wisdom is also apparent. Allow them to infect each other with their
enthusiasm and they will innately work together to build something great.
Someone who is chained to something is not going to have that enthusiasm and
will typically make that known through their mood and action, if not through
complaining. A poor mood is just as infectious as enthusiasm.

My sentiment is that hiring talent and then weighing them down with excessive
restrictions and bureacracy is like buying a Ferrari and driving it 55mph
during the daily commute. Why waste the money on that HP, when you can get a
cheaper vehicle. Let the Ferrari's drive; hire a Civic if that is the kind of
work you are going to give it :)

~~~
codeonfire
>hire a Civic if that is the kind of work you are going to give it

I think people don't necessarily understand the motivations of many people in
management positions. They do not care at all about performance or getting to
the destination. They want to be seen in a Ferrari. Many didn't earn their
positions, suck at their jobs, and will spend the company's money freely to
promote their careers. They are like lottery winner who are just hiring
expensive top people without a plan or experience to put one together. All
they want of the world, all they want, is to impress their bosses and get
promoted. Nothing else matters to them, period. To them, software is simply
one part of the business that is a means to move up the corporate ladder.
Excessive restrictions and bureaucracy don't matter in this environment
because the developer's job is simply to boost the profile of their PHB.

------
crazygringo
> _On a few occasions, someone may suggest that I check out a project that
> could use my help, but nobody tells me what to do._

> _I quickly learned that if I can’t get anyone else interested in the project
> that I want to work on, then either I poorly articulated my vision, or more
> likely, it does not benefit the company._

These appear to be the main points, so there is a kind of pressure to work on
things that benefit the company.

My question is, how does overall strategy get set then? There are probably
1,000 things you could do to benefit the company, but only a small number of
them have a huge effect, some of them require coordination to _really_ help,
and some of them might be diametrically opposed to each other.

Who makes these decisions, when there are multiple viable ways of going
forward, but someone just has to put their foot down and decide which one?

~~~
bkeepers
We have the advantage of using GitHub to build GitHub
([http://zachholman.com/talk/how-github-uses-github-to-
build-g...](http://zachholman.com/talk/how-github-uses-github-to-build-
github)), so we all know what needs worked on. There is certainly some vision
casting from a few core people, but everyone takes responsibility for figuring
out what needs done and coordinating how to do it.

> Who makes these decisions, when there are multiple viable ways of going
> forward, but someone just has to put their foot down and decide which one?

We all do, but whoever submits the first pull request usually sets the tone of
the conversation. Occasionally, a pull request will get abandoned, but usually
it is the starting point and we build from there.

There are often intense conversations about how something should work. I've
learned to just try one way and see if you like it. Not everyone will, but you
can form some consensus.

------
david_shaw
As the director of an engineering team myself, this is an extremely insightful
article.

Bossing people around and utilizing extreme micromanagement might work in
retail (though, honestly, I doubt it), but being a drill sergeant is _not_ the
way to get things done with very intelligent and headstrong individuals in a
technical capacity.

The trick of excellent technical management, to me, is the ability to balance
the business requirements of management with the technical passions of the
engineers. If this balance is off in either direction, the company as a whole
suffers greatly.

Engineers need to be intellectually engaged, and need to feel that they can
make decisions for themselves (even if it's just within the code base). At the
same time, products and services need to ship to keep everyone employed.

It's a tough but rewarding job.

------
petercooper
_I absolutely love the service that we are building. But even more than that,
I love the company we are building._

I think this is one of the strong points of GitHub. Everyone I know who has
gone to work there has a real love for the _company_ as much as the team. I'm
not convinced as many of the many Rubyists heading to, say, LivingSocial
(which has an amazing, all star _team_ ) feel the same way.

The egalitarian approach clearly has some significant plusses, but a downside
IMHO is salary (it has been stated people generally have the same base salary
at GitHub - <https://github.com/holman/feedback/issues/150>). Egalitarian
salary structures work for some but also have their downsides.

------
jessed
I think Github is a special case because at Github they are their own
customers.

Developer/hackers know what other developer/hackers want because they want it
themselves.

It's a great place to be as a developer and as a product company, but I don't
think it's attainable everywhere.

~~~
Kynlyn
Exactly my point. I think what they are doing is great and there is a lot to
learn from it. However, they have very talented developers whose job is to
build tools for other developers. Scratching your own itch is much more likely
to benefit the organization at GH than it is at, say, a corporate IT
department or any other company whose customers aren't developers.

A big part of what makes their culture possible is the product they are
building and the customer that they are building it for. Change those things,
and unfortunately, you are very likely to have to change the culture a bit.

------
siavosh
I wonder if they face the challenge of who has to deal with the less popular
things that need to get done. And at what point resentment might kick in. The
whole thing seems like it can work until there's one bad apple or one
miscommunication.

~~~
bkeepers
That's a question I hear often, or another form of it: "How do you get people
to do things that nobody wants to do?" I usually answer this with two
questions:

1\. If everyone deeply cares about the culture and longevity of the company
(which is a prerequisite), and nobody wants to do it, does it really need to
get done? The answer is often no. But if the answer is yes…

2\. How do you turn that into a celebrated task where everyone wants to do it?

One example of this at GitHub is support. Developers hate doing support. But
we have decided that it is absolutely vital to our company to both provide
good support and to have developers involved in it so we are constantly
getting feedback about what is working and what is not.

So we created the "King of Developers", which is a position that is held by a
developer for one week at a time, in which that developer's primary
responsibility is support. Along with that comes a pimped out desk at our HQ
in San Francisco and tons of street cred. We even have a ridiculous internal
website to go along with it (<http://dribbble.com/shots/554836-GitHub-King-of-
Developers>). There are currently 9 developers signed up waiting to be the
King.

~~~
siavosh
Thanks for the detailed response. At my current work place everyone rotates
through support as well (dev, sales, ops), and I agree with you: the only way
to make these kinds of things work is with an exceptionally strong culture,
and not compromising.

------
gregwebs
Github developers and designers are all big users of the product. I hope they
change how the world works on developer tools. But a different (or at least
very modified) vision is going to be needed at a company working on products
that their developers don't use.

------
kyt
The reason why this environment works at GitHub is because they're profitable
-- extremely so. Money rolls in regardless of what their engineers are working
on. If they were in a pre-revenue state I doubt they would be organized in the
same way.

~~~
jbarnette
GitHub has been organized this way since it was in a pre-revenue state.

~~~
kyt
This is a misleading statement. According to Chris' founder story, they had
customers at launch and he was the sole programmer.

------
ionforce
I find posts like this disheartening. I'm sure this strategy works great for
the upper echelon of developers and quite possibly the vast majority of self-
selected readers of this very site. But there are many companies and
developers that are way down the bell curve that probably could not survive in
this type of environment.

I wish more posts would take into account more factors like sub-optimal talent
or office politics.

------
TwistedWeasel
They say people work on what they want but they still advertise for specific
jobs (<https://github.com/about/jobs>), so surely there is some level of
direction there. i.e. If you're hired as a Data Miner then you are expected to
spend your time mining data, what happens when that engineer decides he wants
to work on something else?

~~~
holman
We've been splitting up into teams (or roles) a bit more as we've grown- it
just helps to keep the focus on things that matter.

That said, the most important part about this is that those teams are
extremely weak. In other words, you should feel strongly able to float between
teams, work on different repositories, or take a week or month off and pursue
a different problem if the problem seems important or if it keeps you happy
and productive.

------
machia
One question comes to mind after reading this, as did with the Valve handbook,
how do you tackle when it is time to "shovel shit"? Meaning that doing things
that are, quite frankly, boring.

------
DonnyV
I wonder how this would shake out in a consulting company?

~~~
ipmb
The difficulty in a consulting company is that (unlike a SaaS company) there
is typically a 1:1 ratio between hours worked and money earned.

Our company does many of the same things, but in the end, we're still tied to
the billable hour. I talked about it briefly here:
[http://lincolnloop.com/blog/2012/may/31/lincoln-loop-
everyon...](http://lincolnloop.com/blog/2012/may/31/lincoln-loop-everyone-
sets-their-own-salary/)

~~~
DonnyV
Wow..just read your post. A couple questions...

    
    
      How many people are in the company? 
      Usually being the owner and founder you get more money. How do you avoid "The boss takes all the money" comment. Not saying you are, but I think this comes   up even if your making only a little more then everyone else. 
      What happens when a developer asks for more money then your willing to give?

------
BillSaysThis
Some orgs just hit the sweet spot for a certain kind of mentality; if this is
reasonably accurate I'm not surprised the most frequent kind of post on the
Github blog is "<your name here> is a Githubber".

