Monday, April 19, 2010

Indie Multitasking

As much as we'd like to think that we are capable of multitasking, we are truly more like an iPad than an iMac. We may have a dozen or more things we have in our queue to do at the moment, but we can only focus on one task at a time. To multitask and actually get two tasks done at once, you need to be two people.

For an indie software company, this means taking a large step and hiring someone—either contract or full time.

This is by no means a trivial decision, but eventually one that has to be addressed. At some point the long days and late nights start to affect the quality of your work or destroy your personal life. And whether you believe it or not, sleep is critical to your health.

Adding staff is hard for several reasons:

  • It costs money

  • It requires trust and flexibility

  • It requires management

  • It requires collaboration tools and processes


Let's take a look at each of these a little more.

Cash Flow


As an indie developer, you probably aren't rolling in extra cash that you can just flash and get more staff. You have to be careful about raising your monthly burn rate. The flip side is that you may be hurting cash flow by doing tech support or marketing when you should be writing code and shipping for-fee updates—I consider myself somewhat of an expert in this type of mistake.

Be smart and take baby steps. Instead of hiring a full-time person, you can pay hourly for contract labor. Last year I contracted with Matt Long to help me with MoneyWell for iPhone development, and recently I hired Ash Ponders, who bills me for the hours he logs keeping our support queue well maintained.

The nice part about contract labor is that you can throttle your spending more with them than you could a salaried employee.

Trust and Flexibility


After I contracted with Matt, I began to think that the amount of code that needed to get written at No Thirst Software was much more than I could do in a timely manner and too expensive as contract work. There was a huge potential for revenue from an iPhone release and a paid upgrade for a 2.0 version of MoneyWell but the overhead of running this company was cutting into my coding time and my schedules were slipping badly. If I had a full-time developer besides myself, I could ship these new releases sooner, which would be a huge win for both the company and our customers.

I've hired developers many times before in my previous companies and I knew the pitfalls. Hiring a skilled developer is important, but even more important is hiring someone you trust and can work with. I've hired prima donnas that code well but are impossible to work with and nice guys that really can't produce the code needed—neither hire is good.

I like to hire developers that I've already spent time with and have learned about how they code and think. That meant my list of potential employees was very short. To shorten my list even more: all of them had good jobs already and didn't have a strong desire to jump ship.

The stars aligned for me and one of them became available at the perfect time. I hired Michael Fey (a/k/a the infamous MrRooni who started a rumor about spotting Steve Jobs at WWDC 2009) as my first full-time employee in January 2010.

Check this out: I first knew Michael as an early MoneyWell customer who was generous and helped out by answering questions on our support forum. I later found out he was a Mac developer and then was lucky enough to spend some time with him at WWDC and really get to know him. This is one more reason why you need to socialize and network. You never know if you are going to meet a future employee or employer. Needless to say, I'm thrilled to have someone who knows our products, is a skilled developer and is joy to work with on a daily basis.

Now, this is where the flexibility comes into play. When you bring in someone else to do the work you once did in your isolated "me" universe, you'll find that they'll do the same tasks a bit differently that you did. If you can't deal with that fact, you can't have employees and you can't ever expand your company. You have to be flexible and accept that your way isn't the only way to get something done. I've learned something from everyone I've ever worked with—without exception.

Managing People and Resources


The minute you add any person or service to your operation, you become a manager. It's your job to steer the ship and control the future of your company. This doesn't mean that you have all the answers, it just means you have to make the final decision. With employees comes payroll. With contract work comes more payables and tax paperwork. There is overhead to even adding one person.

There's also mentoring and training. If you fail to properly mentor your new hire in the company processes or train your support technician in your software, you can't expect that person to perform well. This is your primary job as a leader. and ignoring it is like planting a garden but failing to feed and water the plants. All your initial effort will wither on the vine.

Tools and Processes


Before you expand beyond a one-body shop, you have to invest some time in collaborative tools and processes. For an indie software company, the three biggies are support, bug/feature tracking and source code management.

Email-only support systems are incredibly hard to maintain with more than one person. Did that email get answered? Was there a response? Who's checking for new emails? Has this customer had similar issues before?

We use Tender to manage our support because it gives us a way to coordinate and assign support. It also suggests Knowledge Base answers when customers post questions so some customer get immediate, automatic support. It also has custom queues that notify specific people in our company when help is needed. This way, our frontline person can get emails for all support issues and the rest of us only see what has been escalated. Additionally, the discussions can be public—the customer can choose to make it private—so other customers tend to jump in and help. I'll take all the help I can get and often, our customers know better answers than we do because they have personal experience with the question.

For bug/feature tracking, we chose Lighthouse, which happens to work well with Tender because ENTP makes and runs both. What I needed most in issue tracking was a quick way to create requests when customers report bugs or asked for features. Because Lighthouse and Tender integrate perfectly, creating a ticket in Lighthouse requires only a couple of clicks upon reading the Tender discussion post.

There are many different needs for both these tasks and you may need a more intense issue tracking system. I like to avoid complexity as much as possible and that was a driving force in my choices.

Picking a source control management system is like choosing an operating system or development framework. You're not going to convince a .NET guy that Cocoa is better any more than you can tell someone who loves Mercurial that Bazaar is better. It really doesn't matter what you choose, but pick a distributed system that has a cloud presence. I used Subversion, then switched to Bazaar and finally ended up with Git.

The primary reason for going with git was Github. I had to collaborate with other developers and they were already using Github so I was flexible and adapted. Once I learned the (sometimes weird) ways of git, I was productive and happy. Moreover, my team was able to work together easily. I needed four developers in three different parts of the country to work out of the same repository and Github made that happen.

Galactic Headquarters


The Galactic Headquarters of No Thirst Software LLC are in my home office located in The Woodlands, Texas. My full-time developer is near Syracuse, New York, contract work is done from yet another state, graphic design is coming from Europe and Ash is doing support from who know's where on the planet. I have to admit to a bit of envy towards my globe trotting support ninja.

My point is that the days of renting office space and hiring employees locally so that they can show up to work in a central location are long gone. It makes no sense financially and only offers a slight collaborative advantage over Skype and video conferencing. When you pick tools or decide on processes, make sure you think global.

We have office chatter over Twitter, share documents on Dropbox, manage projects on Lighthouse, review support issues on Tender, share source code on Github and hold meetings on Skype or iChat—our work day revolves around information stored on or shared over the internet. I've never run a company this efficiently with such a small amount of overhead. It's a great time to grow your operation and expand beyond yourself.

Peace.