Jay Paroline

There’s no room for ego in software development, and especially if you are a small startup setting out to change the world, there’s no room for ego on any team.

Here at Grooveshark, we have the smartest bunch of people I’ve ever worked with (and they’re not paying me to say that), but we all make mistakes, have a bad brain day and make less than optimal decisions sometimes. When there is no ego involved, we can all point out to each other when one of us is being stupid, and we can easily own up to our own mistakes and learn from them (and make the site better), and we can ask questions when we don’t know something.

If ego is involved, it’s no longer easy to tell someone they are doing something wrong or question their decisions, because you might hurt their feelings. Conversely, if you are maintaining an ego, you’re going to have a hard time admitting that you don’t know things that you need to.

Either way, precious time and resources end up being wasted, either fixing bugs, redesigning architecture or spinning your wheels trying to figure out something that someone else probably already has the answer to.

I ask my co-workers probably hundreds of questions a day. I’m not an expert on the way every single piece of our site works and it doesn’t hurt my ego to admit that. So when I find a bug in, say, the recommendation engine, I can go over to Travis who seems to know that system inside and out, and ask him exactly what is happening. I don’t think Travis has any less respect for me for it, but now I know more about how that part works and I fixed the bug, so now we have a better product, and it only took me a few minutes because I didn’t have to analyze each line of code tracing through the object hierarchies, etc.

When we have to design an important new feature or revamp the way part of our architecture works, we have a meeting about it and everyone provides their input. We usually start out with a few different ideas and everyone argues and makes a case for their idea. In the process of doing that we change our minds and come to a consensus. Because there’s no ego involved, we’re each prepared to give up our idea if a better one is presented, and we usually end up coming up with a solution that is better than what any of us would have designed on our own.

This concept applies to other teams/departments as well. In my experience, those teams open to constructive criticism from outside the group are the most effective, and those that are least receptive to feedback tend to have lower quality solutions.