• What would I look for in a co-founder?

    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.

  • The importance of employee recognition

    I think employee recognition is an area that’s grossly undervalued, both by managers and by people in general – especially when it comes to knowledge workers.

    Knowledge workers get paid reasonably well. If not, they know they can go somewhere else and make good money. I find that engineers, as a rule, are very good at crafting a world that works for themselves. Maybe because it’s easy to do. But crafting a world that works for others – not just yourself – is much more difficult.

    Happily going to work

    In my experience, when it comes to work happiness has everything to do with WANTING to go to work each day. I never WANTED to got to school, but I put that life behind me 12 years ago when I started my first company and I’ve never looked back or given it another thought since.

    Do your employees find themselves in a place where they WANT to go to work? Beyond money, an important way to make people WANT to come to work for you is to recognize them when it’s warranted and make recognition a systematic part of what you do so it actually gets done.

    Getting yourself in the habit and out of the way

    To some degree, in order to put other people in the spotlight, you have to step out of it, which entrepreneurs have a terrible time doing. For some people it’s a zero-sum game – they care too much about themselves. But those are not the type of people you want. You want people who feel good about making others feel good.

    It’s very easy to follow the path of least resistance and recognize only those near to you, while forgetting everyone else. It’s also very easy to put off or completely forget to recognize exceptional people without a conscious, ongoing effort. Keeping a spreadsheet or other system where you can record when someone does exceptionally well that also includes your ideas on what you plan to do for them works really well. Otherwise, its too easy to forget and go about your day.

    To get employee recognition right, it needs to be an integral part of your regular routine. You need to hold yourself accountable for recognizing your employees in some structured way and make time for it. Otherwise it won’t happen. And, when your top performer turns in his or her resignation, your day will be about to get a lot busier. Then it will be too late.

  • Managing stress

    I saw an interesting article recently titled “What is the Most Difficult CEO Skill? Managing Your Own Psychology” by Ben Horowitz on TechCrunch. In it, Horowitz talks about the stressful aspects of being a CEO (there are many) and shares some techniques he uses to calm his nerves.

    The startup environment is frothy now. Money’s coming back into play and investors are looking for the next big thing in tech. Sound familiar? When the market heats up, so does the pressure. So I got to thinking about stress, how it can impact the quality of life and some of the things I do to help manage it. Stress is important. 90% is self imposed or imposed by other people and it doesn’t help you. So why are we so bad at dealing with it?

    There’s nothing good about stress

    I’ve yet to to see any truth that stress does anything good for people. Sure, there are those out there who claim, “I perform well under pressure.” That’s just a total load of bull to me. I’ve never seen anyone under stress perform better. In my mind, people who say that are either going to perform well anyway, or they’re constantly putting themselves in a position where their backs are against the wall. To me, anyone who says they’re only good under pressure is sending out a big, bright red flag.

    How I manage stress

    Naps. If you know me at all, you know I’m a fan of taking naps. I’ve even written about why you should insist on taking naps and if you can’t nap, meditate. I take naps every day if I can because I find it’s a HUGE stress reliever. I’ve never woken up from 15 minutes or more of napping and still felt stressed. Most times, I can’t even remember what was stressing me. I consider taking naps a form of cheating life – an “unfair advantage” of sorts.

    Journaling and talking to myself. I also do an insane amount of journaling using Evernote. At last count I think I had 11,000 Evernotes. I talk to myself at every possible opportunity – or type to myself if I’m not in an open setting where someone might think I’ve lost my mind. I use a digital voice recorder and talk about whatever things are starting to interest me at that moment. I think these habits are compatible with two techniques Horowitz mentions in his article: “Make friends” and “Get it out of your head and onto paper.” Oftentimes people need someone to talk to. You’re probably most compatible with yourself, so talking to yourself out loud and journaling makes perfect sense to me.

    Getting into student mode. I find I’m most productive and least stressed when I’m in what I call “student mode.” When I’m in student mode, my attitude is “I’m here to learn, it’s okay to be wrong.” In student mode you can meta think – what’s the best way to solve this problem?

    Student mode entails asking ourselves things we might have asked when we were in school but don’t ask ourselves in real life. In school, you don’t really think so much about the fact you have a problem. Instead, you’re thinking, “How do I solve this in the best way?” – or “How do I handle this to get the best grade?” Mentally, student mode has been a huge win for me. I tell myself, “Don’t forget you’re a student of entrepreneurship. This is your life in the classroom. Let’s think through the current challenge and potential solution options and then work through it”. Student mode mentally/emotionally removes me from the situation. It’s like I’m someone else looking at my life.

    Staying in control

    I feel like I’m pretty chill most of the time. I see flying off the handle as a sign of weakness; a character flaw. If you can’t control yourself, you need to go back to square one. Do not pass Go; do not collect $200. We all need ways that work for us to relieve stress so we can stay calm under pressure. It’s just (an important) part of life.

  • A followup on rapid prototyping

    In an earlier post, I offered some thoughts on rapid prototyping. I mentioned my preference for the “high-fidelity prototype”, which leaves very little room to the imagination and provides users and stakeholders with a realistic sense of the user experience of the product.

    I’ve been using a couple of different rapid prototyping tools and thought I’d offer some opinions on their limitations and what looks promising as I see it.

    Rapid prototyping tools

    I’ve been using Balsamiq and Axure a fair bit. I think they’re both pretty good tools, but the problem is prototyping and design are subsets of communication and these two tools don’t seem to get that.

    You don’t come up with a design in isolation, you need to validate it with users and other stakeholders. For the most part, these tools make it easy to put UIs together, but they have issues when it comes time to send out your work for feedback. The biggest problem I see with both is managing workflows in the review process.

    Because they’re desktop based, you need to make all supporting files accessible to your reviewers and provide instructions to them for getting the prototype to look and act like it’s supposed to.

    In reality, by the time someone gets to the review, you’ve already made changes. Every time you send out a new iteration, you need to include lots of attachments and send everything out all over again. Getting timely feedback can get so aggravating that you reach a point where you don’t want to bother doing it at all. Major pain.

    And then there’s ProtoShare

    I got to thinking, “There must be a better solution, even if I have to build it myself”. Then I discovered ProtoShare.

    There are several things I really like and admire about ProtoShare – both the company and the tool, including:

    • When you first go to ProtoShare’s website, they talk about design as a form of communication, which I agree with and relate to. They seem to “get it” in that regard.
    • With ProtoShare, I can prototype in a browser but can also link pages to one another. Even though they’re just sketches, at least I’m able to link to them. Axure can do this too, but it’s a desktop tool so everything has to be uploaded somewhere.
    • The killer functionality with ProtoShare is its one-click publishing capability. You can prototype your whole site and then publish it to a live link to be shared with others to get feedback.

    Another advantage ProtoShare has against Balsamiq is ProtoShare uses built in Javascripts. Every time I use a Flash or Flex app, it doesn’t feel like a web application because of the way it handles scrolling, right clicks, text highlighting, etc. It’s the “Adobe way” of doing things that, to me, is just plain annoying and doesn’t feel natural.

    A few shortcomings

    The shortcomings I see with ProtoShare center mostly around pricing.

    • First, it’s not really cheap. The Professional version is $49.99 per month. For that you get up to 3 users and 10GB of web storage. Additional users cost $25 each – every month.
    • If you want to get feedback from someone, that someone needs to be a ProtoShare user. I really don’t see asking my reviewers to become ProtoShare members.
    A step in the right direction

    While it’s not perfect, I see ProtoShare as taking rapid prototyping to the next level. It’s not just wireframing, it’s really a collaboration and communication tool. Because it’s built in JavaScript, it feels native and not clunky. All in all, I’m a pretty big fan.