We hit the "opinion overload" problem at dotCloud about a year ago, at 10 employees. It took us a while to fix it. We could feel the beginning of a vicious circle where an eloquent opinion brought the same peer recognition as a working piece of code. The symptoms were more talking, less coding, recurring debates which everybody was sick of but nobody could put to rest, and worst of all, a tendency to say "I told you so" and blame each other for oversights. We noticed this when junior hires started mimicking the most verbose "opinionaters" instead of the most prolific doers. The wrong "genes" were reproducing in the company's dna!

Fortunately we found a solution and the group self-corrected wonderfully. The team is now 20 strong and an awesome no-bullshit engineering culture. We found that the key to a constructive conversation is to have an owner: someone in charge of the subject at hand, who is held responsible for the result, and in return has authority on how to go about it. Everyone else in the conversation is a peer, voicing their opinion non-authoritatively and acknowledging that the owner has the final say. Rule of thumb: ask "who's the owner?". If there's no clear answer, you're not getting work done.

In a group of smart and trusted people, this creates a culture where you earn your spurs with what you do, not what you say. Opinions become more like washing the dishes: useful and necessary, but not something that will get you pats in the back either. In fact if you take your dishwashing skills too seriously you might find yourself a source of amusement.

We later found out that Pixar uses a very similar peer feedback system for its productions.

Having strong opinions is different from having an opinion on everything.

Being in a place full of opinionated people is nice, so long as those people are able to discuss their opinions rationally and are okay with not getting their way every time.

"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

"Have strong opinions - weakly held" is probably what he meant: http://www.codinghorror.com/blog/2008/05/strong-opinions-wea...

One should be able to hold multiple conflicting ideas in one's head (double think), each with varying amounts of evidence depending on the current situation. Furthermore, one should be able to switch between said ideas quickly and easily depending on what is needed to successfully complete the task at hand.

For example:

If you want high perf/dollar when doing a data analysis across billions of rows you know that you should run on a commodity cluster and with bare metal high performant C++.

You also know that if you want to get something done really quickly (elegant - not performant/efficient), you stick to what you know (Python/Ruby/Perl etc.) and get it done today. You know that if need be, you can just scale it out later with a more performant architecture.

Both opinions are strong. Both are weakly held. The best one wins depending on the situation.

Everyone's different, and that makes for a great number of different strengths and weaknesses. The biggest problem you run into with opinionated people is that they're frequently more interested in offering their opinion than doing anything about it. On the other hand, that means there's no shortage of constructive criticism when you want it.

In short, opinionated people are just another type of person you have to deal with. If you can't make yourself be as opinionated, that's no big deal. If this is a significant problem for you, perhaps it's best to figure out what skills you have that would complement "opinionation".

Have you ever taken an MBTI test before?

We have the advantage of using GitHub to build GitHub (http://zachholman.com/talk/how-github-uses-github-to-build-g...), 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.

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.

I think this depends on what you mean by "the less popular things that need to get done." In my experience, things that were less popular at other places I've worked, are often tackled with enthusiasm at GitHub. When the company culture leads you to feel passionately about building something lasting, going back to clean up old rotting code or fix tests that were not written well or debug obscure issues become things to be proud of.

Also, I believe that often the less popular work corresponds to things that are subtly judged to be less valuable work. At GitHub, I see people praised for tackling the types of things that have been less popular at my other jobs, and everyone here, even the most prominent GitHubbers, participate in most every aspect of maintaining the product. Internally, the message is pretty clear - doing the things that "need to get done" is a huge part of what makes everyone else here proud of you and is valued highly.

This is not to say that people don't tire of working on particular areas, but that's a somewhat different issue and probably a large enough topic for a writeup of its own.

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.

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

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.

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

  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?

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

Free of influence from investors/meddlers.