One of our investors asked me an interesting question recently:

If you had to do it over again, how would you describe the background that you would have loved to have coming in as the technical co-founder of Modcloth? What technical skills as well as soft skills do you think would be helpful to have in the initial stages and as you scale as you have done?

This got me to thinking. If I was looking for a technical co-founder today, what would I look for? I think it’s a timely question considering the startup environment right now, and it’s possible (maybe even likely) that some of you are asking yourselves this question right now.  So hopefully you can benefit from some of the experience I’ve gained over the years.

Without further ado, my co-founder wish list:

• Someone who’s failed at least one (preferably 2-4) significant software projects in the past. Nothing teaches you about the reality of software development more than failed or canceled projects. In fact, working on a failed project is probably more important than traditional ‘agile’ methodology experience. Why? Because nothing teaches how to ‘unbundle risk’ better than having had the rug pulled out from under you in the past.
• Someone who’s had to answer to real people and has had to compromise on product vision. Client services experience could be a plus here. A lot of technical people are uncompromising in the wrong ways. They think they are experts on the product and fall far too in love with their own ideas. (Sadly, a lot of stupid companies get started this way…)
• Someone who’s had to play all roles. (Think ‘independent freelancer’ who has to do a little bit of everything, again in the name of client service.) Someone who has had to actually fix bugs in IE6, make rough prototypes, slice PSDs, and configure the database server will have an appreciation for all the moving parts of a good engineering team.
• Someone experienced with scale. From a purely technical standpoint, having built or maintained a system that has scaled significantly will go a long way. (It doesn’t have to be scaling on an insane degree, a la Facebook, Groupon, etc.)
• Someone who’s not overly academic. Designing an application the way the ‘textbook tells you to’ often doesn’t scale. But hey, at least your code will look good when the site goes down : )
• Someone who knows how to ‘go fast’. This is paramount because the burning needs of a rapidly scaling business wait for no one.
• Someone whose #1 core competency is learning. Technology stacks come and go. You want someone who learns at an insane speed. (I used to mini-test engineers in a language they didn’t know, on purpose. It worked wonders.)
• Someone who understands fairness. As the team scales, you need someone who is level-headed and willing to take all perspectives into account without playing favorites. I bring this one up not only because it’s critical to keeping a team engaged, but because I see it rarely.
• Someone who can keep their calm at all times. People who fly off the handle suck. No one wants to work for a ticking time-bomb. Furthermore, bad stuff *will* happen. Sites go down, get hacked, etc. Being able to keep your cool makes all the difference in terms of getting stuff fixed and not losing half your team to ‘asshole attrition.’
• Someone who knows how to ask questions. A key soft-skill is knowing how to ask questions as opposed to giving answers. I see the opposite *ALL THE TIME* with good engineers. They don’t know how to shut up, and they take up too much airtime. Top talent doesn’t want to be told; they want to be asked. The secret to getting the best out of a good engineering team is learning how to STFU.
• Someone who knows how to write code. Beware of the people who “don’t write code, but know how to architect.” If you’re not writing code, you’re not architecting. Period. Anyone can draw a relational-model diagram. I’m not saying the person needs to be a hard-core coder…but if they are afraid of touching the keyboard, you have a problem on your hands. The reality is that you won’t know how good it is until the rubber meets the road.

Grounded in the real world

Doing things the right way technically (I’ve always liked using the term ‘better practices’, not ‘best practices’) takes a lot of time and effort. When you’re young and a founder you want to do everything the right away and have working code in the morning. You want people who understand how to make those investments/tradeoffs the right way – they understand there is such a thing as overegineering and going too fast. Someone who knows from feeling the pain – who’s done it both right and wrong and has a good alignment between the two.

In the real world, the pendulum swings. One time you might overengineer and then know you need to cut back next time and vice versa. In addition to the characteristics in my wish list, for a co-founder I’d want someone with a balanced background in reality who can settle into a healthy middle ground.