Going Indie – How to Handle More Work, Better

This is the second post in a multi-part series on becoming an independent software consultant. The focus of the series is to share my experiences, accomplishments and shortcomings in the process of building my own software business.

You may not be surprised to read that this post is all about delegating. Most engineers and aspiring business owners know they need help. They feel the pain of not having enough hours in the day and often feel trapped by obligations that prevent them from finding help and transferring knowledge.

I continue to make this mistake myself even as I delegate regularly to many engineers and designers. I consider it a failure of the imagination more than a failure of planning. The more hands-on work I do, the less I consider the big picture–why I started the company in the first place.

For all small-business owners who struggle with delegating, I highly recommend the book, The E-Myth Revisited by Michael Gerber. The myth at the heart of this short read is that which builds up the entrepreneur as a distinct type of person with the special gift of spinning straw into gold. In exposing this myth, Gerber challenges you as an entrepreneur to build your business with multiple departments in mind, from day one.

While you are still your company’s only employee, you should run it like you are the CEO managing multiple distinct operational units beneath you. For a software engineer, this means at the very least you should have three departments:

  1. Sales
  2. Engineering
  3. Project Management

You can probably skirt by in the early stages without much Marketing or Quality Assurance, but you should think about them as opportunities for improving and expanding your business.

Document What You’re Doing

As soon as you recognize that as a freelancer you are already fulfilling these three roles, you can start thinking strategically about each of them. Take the time to define these roles and create written documentation, play-books if you will, that outline your vision for how those roles should handle their respective responsibilities.

You’re doing this for two reasons:

Firstly, the short-term benefit is making you better at what you do. For things you are comfortable with, like engineering, it will help you identify what’s working well and what’s not. From there you can solidify the former and challenge assumptions for the latter. You can test and re-test new methods until you fine tune every aspect. For things you aren’t comfortable with, like sales and marketing, it will prevent you from ignoring them. You have to face them head-on and start experimenting to find out what works for you and what doesn’t.

Secondly, when you’re faced with too much work and too little time, you won’t have to make the same mistake others are making. You won’t have to worry about losing time getting a new employee or subcontractor up to speed. You can just share your playbook and get back to more pressing matters.

Delegate What You Know

Everything can be delegated, but not everything should. You’re going to gravitate toward handling things you’re familiar with and getting others to handle things you’re not comfortable with. If you’re an engineer, you’re instinct will lead you to continue programming to the fault of ignoring other areas–areas that will grow your business. You have to fight that urge.

Delegate what you know first. If you’re an experienced programmer this should be relatively easy. Write a style guide that covers everything from library management to functional testing. I recommend avoiding petty topics like cuddled “elses.” Programmers rarely adhere to these items and having newline syntax consistency has absolutely no real bearing on whether your company is delivering quality products. It does not prevent new developers from grokking existing code. It’s much more critical that you have a solid testing harness than to worry about syntactical idiosyncrasies.

Make sure your subcontractors read and understand your style guide. Ask them if they disagree with anything. If they disagree, listen to their opinions. Give them a voice to help define the process. The more you value their opinions–even as subcontractors–the more likely they are to work with you again. As you work with the same contractors time and again, you’ll notice that communication overhead drops and quality increases. That’s more time for you to focus on improving your business (or maybe just duck out for a movie in the middle of the day). 

Read the next post in this series: Going Indie – What it Means to Be Done or follow me on twitter: @frivolousjosh

Share on LinkedInTweet about this on TwitterShare on FacebookShare on Google+Email this to someone

One thought on “Going Indie – How to Handle More Work, Better

  1. Pingback: Going Indie – On Becoming an Independent Software Consultant | Joshua Stephenson

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>