Going Indie – On Becoming an Independent Software Consultant

Recently, iOS extraordinaire and all around great guy, Brandon Treb, and I were brainstorming a book documenting our own endeavors into independent software consulting, when we decided that a series of blog posts would do just fine.

We both spent years programming for others and eventually developed the itch to handle all the elements of software services. In doing so we’ve developed a number of practices and methods that work well for us in all topics from marketing and sales to recruiting and workflow. We recognize that different things work for different people so decided that writing complimentary posts on the same topics would do our readers the most good.

Before we get into the details you might like to know more about the history of our work experience as that clearly has a lot to do with our success as independent consultants. I can only speak for myself but I’ll link you to Brandon’s post below.

There are plenty more successful software consultants than me. Tons. This is not meant to be a dialogue about becoming a millionaire consultant. No, if you want that, read Alan Weiss or Harry Beckwith. These posts are for people who love software, want to tailor it to their clients better and want to gain a significant amount of personal freedom in the process.

Some Background

My career did not include much schooling but it did include a lot of learning on the job. From age 16 I was working with cars in an auto-mechanic shop in Albuquerque, NM and at 18 I was working for an independent Internet Service Provider. I never was satisfied with the shoes I was asked to fill, always trying to make them larger. At the car shop I was hired to assist the mechanics and pump full-service gas, check oil and shut the place down at the end of the day. I was lucky when a customer wabbled their car in for a tire repair or when I got to do an oil change on a slow Saturday afternoon.

At the ISP I was constantly looking over the shoulders of the sysadmins learning the ins and outs of FreeBSD servers and Cisco routers. I learned C previous to the job from Kernighan and Richie’s famous book simply title “C” but the time came that I wanted to develop websites, dynamic ones that I could change with content and not code. I had taken HTML and CSS as far as I could and JavaScript was still a bad word so I needed something in between HTML and C.

At the time, the web world was just emerging from the world of perl scripts and cgi-bins into the up-and-coming stage of PHP. I learned the ins and outs of PHP and MySQL and learned to love building experiences on the open web.

Eventually I decided I wanted to get out of New Mexico and go coastal. I started browsing craigslist for web developer jobs in Los Angeles and eventually found one for a Ruby developer. I managed to learn enough Ruby to fake my way into it, as most engineers have done at one time or another. I spent half a year in LA building an online portal for an urban magazine when I started to smell the scent of bad management and impending layoffs. Just two months before the company laid off three quarters of the staff I was referred to a growing ruby consultancy in Santa Barbara. This would become one of the most formative jobs of my career.

The founder and I had similar personalities and as a young bachelor I wasn’t opposed to him throwing me into awkward situations far out of my league and doing my best not to embarrass myself and the company. During those years I found myself in cities across the states, Canada and western Europe working with startups and large enterprises like Disney, FunnyOrDie, ESPN and the Tribune. At the time I thought the majority of what I was learning was about programming, but really what the job was teaching me was understanding product needs and fulfilling them by building solid teams with good practices.

The second most formative job in my career came after I had already transitioned to a full time iOS developer. Ruby had lost it’s glam and everybody wanted to push the limits of the new iPhone. I was recruited by a classy recruiter (there are tons of recruiters out there and only a handful of classy ones) to join the “digital agency of the decade” in NYC. Living in NYC had long been a dream of mine, and literally being invited to live and work there was an easy choice.

Working for an advertising agency is very different than a tech consultancy. Most of the work in the ad world is led by strategists and creatives, where engineers often do not have a fun time. While it’s easy to be frustrated by this, and believe me I was, I did my best to work my way out of it. I made opportunities whenever I could to get my face in front of the company so I wouldn’t be stuck as a code-jockey.

The ad world was a great compliment to my experience in the tech-scene. Planning products based on industry trends, brand ambitions and designer day-dreams can challenge the assumptions you make as a developer and require you to look at problems differently. Even at the worst ad agencies, when developers and designers find a way to collaborate they are able to build amazing things.

Identifying Opportunity and Value

I had other jobs in this time frame. I had project based jobs for other ad-agencies. I had jobs for startups that failed miserably. I had technical instructor jobs and sysadmin jobs for universities. I even had jobs that weren’t even software related. If I had told you the whole story front-to-back it would have appeared as a jumbled mess leaving you wondering “WTH do I have to learn from this guy?” Like many things in business it’s about finding the signal through the noise. If you’ve been in the industry for a few years and had different positions with different challenges, you will find that you have a wealth of experience to draw upon when you start asking yourself questions about what you really want your career to look like.

For me it came at the ad agency. Being an engineer in the city, in the age of social and mobile is a weird experience. People like me were in such high demand that recruiters stopped calling us on our cells and home phones, and started calling us on our desk phones at work! I’m amazed at the brass but it’s true. Not only that, but my friends working in all different industries wanted time to talk about startup ideas and projects to see if I had advice. If you’re a technologist then you know what I’m talking about.

If you’re not paying attention it’s easy to let these conversations end with just simple advice; to provide direct answer to questions. When you realize that what they need more than anything isn’t answers, it’s competency and ownership, then you are able to change the nature of these conversations. They aren’t about advice anymore, they’re about work.

Then it’s just a matter of bridging the gap and that’s exactly what these posts are about.

If you’ve had that moment and you want to know how to move beyond the tech-buddy, read the next post in this series:

Going Indie – How to Handle More Work, Better

Read brandon’s post here and follow me on twitter if you wish.

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

2 thoughts on “Going Indie – On Becoming an Independent Software Consultant

  1. Pingback: Becoming A Software Consultant: My Backstory | brandontreb.com

  2. Pingback: Going Indie – How to Handle More Work, Better | 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>