08 Feb 2016
Will you work for equity?
After you have been consulting for any amount of time, you are bound to get asked this by a client. You may find yourself struggling to decide whether or not to take some equity or just get paid to work on the project like you normally do.
I had one such scenario a while back that I wanted to share. One day a few months ago, I was approached by a local VC in town. Our relationship falls somewhere between acquaintance and friend; let’s call him Joe. Joe has a very successful background and is one of the more wealthy people in my circle of influence.
Joe asked me out for beers to discuss a new opportunity for a mobile project. I, of course obliged and met him out. During this meeting, Joe proceeded to tell me about an application he wanted me to build that would be aimed at teenagers. The gist was:
They would create rooms and the "cool kids" could vote other kids in and out of the rooms.
The offer he made was 30% of the application ownership and profits and a small share in one of his existing startups. Given Joe’s history, I knew this would most likely be a successful endeavor, however I told him that I had to think about it. Given the nature of the app, I had some strong moral objections to creating a tool that would allow teens to ostracize each other. This didn’t quite sit right with me.
After taking a few days to think I it, I ultimately told Joe that I didn’t feel right about working on the application. He said “no worries”, and that was the end of that conversation.
6 Months Later…
Some time had passed and Joe and I eventually met up for beers. After a bit of discussion, he said “Hey, I wanted to tell you about that app”.
He then follows with “I found a college kid to work on the application and gave him the same offer that I gave you. I also had a designer do some very basic mocks of the application. While I was out on a trip to Silicon Valley, I mentioned the application to a good friend of mine at Facebook. Well, Facebook has a similar product coming out (turned out to be Rooms) and they decided to give me a quick check for $1.1mm to discontinue work on the product. I then wrote the college kid a check for $333K before he’d written a single line of code!”.
My immediate thought was “at least I still have my values”. It’s pretty funny to look back and think about how I could have made so much money so quickly. However, even if I had known the potential payout up front, I don’t believe I would have still taken the project. It would have eaten me up inside.
The takeaway of this story is twofold. First, I’d urge you to choose your compensation wisely. Before this encounter, I would always give a hard “no” when asked about equity share as part of compensation. I now take it on a person by person basis. Second, don’t compromise your morals for money. I look back on this story as a success and wouldn’t change a single thing about it.
25 Jan 2016
Want to jump ship and be a software development consultant? This post will detail why this path is a much more fulfilling and safer path than a traditional job.
Early in my career, I worked for a software consulting agency. I was in my early 20’s and getting paid way more than I should. One day, my boss called me up and let me go without notice.
After interviewing quite a few developers in the consulting space, I quickly realized that this is a very common story. If you work for a company, they can usually let you go at any time for any reason. Given that this is your sole source of income, you are now in an extremely risky situation.
Contrast this with being an independent consultant. Most likely, if you are consulting you have 1 or more clients. In addition to that, you have some sort of pipeline set up. So when you lose a client, you simply pull another from your pool.
Mo Clients Mo Money
The going rate of a senior software development consultant is between $100-$125/hour. At this rate, you are looking at pulling in somewhere between $16K-$20K/month.
Working for a traditional company, you would be hard pressed to command this salary even after having 10+ years of experience. I’m not joking, kids who learned to code on Udemy in 6 months were making this while I had a salary cap of around $100K.
In the U.S. , car accidents are one of the leading causes of death among young people. Obviously, consulting can help mitigate this risk by allowing you to work from home or close to it. Therefore, further limiting your physical safety risk.
In addition to limiting safety risk, not having to commute has financial advantages. Since going independent, my family has cut down our need to a single vehicle saving us money on car payments, maintenance, gasoline, insurance, and most importantly time.
Flexibility Of Location
When you don’t have to work in a traditional office, you are free to work anywhere in the world. This could be coffee shops, the park, or even on a cruise ship.
I typically like working in my shipping container office (post on that in the future) or wherever my wife has chosen to take the kids on a field trip that week.
Flexibility Of Time
When I worked at a traditional company, I was required to be signed in and available from 9-5 Monday - Saturday. As you can imagine, this has a huge impact on how you plan your free time. It’s also extremely limiting when you are trying to plan a trip or vacation.
As a consultant, you have 100% control over your time. This allows you to live life more on your terms. If you enjoy staying up late and hacking until 3am, you can then enjoy sleeping in until 11.
My wife and I currently homeschool our kids. So when we want to take a trip, it’s literally a matter of leaving our house. We don’t have to ask for time off, we don’t have to plan around other people. We can quite literally drop everything and head to Disney World during the “deadest” parts of the year and enjoy doing things while others are “working”.
I have found this level of flexibility has greatly improved my quality of life.
This sort of goes with what I said above. Traditionally, if you want to take off time you need to:
- Make sure it's cool with your boss
- Make sure it's cool with your team
- Give 2 weeks notice
- Fill out paperwork
- Burn through your limited "vacation days"
- Still take calls from vacation because your are a "nice guy/gal"
When you are a consultant, the process becomes:
- Leave for vacation
You Are Your Own Boss
"So, Peter, what's happening? Aahh, now, are you going to go ahead and have those TPS reports for us this afternoon?" - Bill Lumber
I never want to have a “boss” again. It’s true. I hate the thought of someone constantly breathing down my neck watching my every move. I also can’t stand the idea of someone giving me a ”performance report”.
When you become a consultant, it should be obvious, but you are the boss. Early on, I would make the joke when my wife asked me to go on a random adventure “Let me check with my boss”. Hilarious right?
Working In Your Underwear
Unless you are a Victoria Secret model, chances are you actually have to put on pants to go to work. Not with consulting! I’m so glad I met my wife before I became a consultant, otherwise there would be no chance of me landing her wearing some of the choice outfits I do during work hours.
I find my level of quality goes up with my level of comfort. It never made sense to me why companies preferred “business casual” over “sleep professional”. Seems like millions in lost revenue.
This list is in no way meant to be exhaustive. These are just some of my favorite perks that I have been enjoying over the years. If you have some others that I have missed, please feel free to add your comments below.
11 Jan 2016
As the new year kicks off in full swing, I am reflecting on my 2015 goals and setting some new ones for 2016.
Here is how I did on each of last year’s goals:
- Create a business plan - Fail. I did not create a business plan for Pixegon. This might have to carry over.
- Grow Pixegon (my mobile consultancy) to 2x 2014 revenue - Success. We not only achieved this goal, but surpassed it. Pixegon did a total of $1.1mm in revenue in 2015!
- Hire a “director” - Success. OK, so this one is sort of in the middle. I didn't quite hire a director per se, however I did elevate my senior employees to more management roles. This allows them to take some of the day to day tasks off of my plate.
- Move to a weekly - Fail. But I'm OK with it. This isn't very important.
- Morning Routine - Moderate. Some days were better than others
- Blog twice a month - Huge Fail. I averaged .41 times per month.
- Take off / reduce workload - Success. More camping!
- Give away more than 10% of personal income - Success. Our family was blessed with multiple opportunities throughout the year to be a blessing to others in addition to our normal donations.
Overall, I’d call 2015 a success. I managed to hit the goals I felt most passionate about, and more importantly, this exercise has helped me to determine what I should focus on. With that being said here are my goals for 2016.
- Land ONE new client. Sounds crazy I know, but allow me to explain. Pixegon has been fortunate enough to work with some pretty incredible clients. Many of these clients trust us to be their primary dev team throughout the year. I intend on finding at least ONE more client like these in 2016 (Referrals welcome ;) ).
- Build Something New. As I continue to build a company, it's often hard to get back to my roots of writing code and actually creating something. I miss this. It provided so much value to me over the course of the years. So, this year, I want build some "side projects".
- Hire. I hope to grow the team by at least 20% this year. (We are always hiring most positions).
- Be more intentional about EVERYTHING. I have really been into a few blogs lately (Mr Money Mustache, The Minimalists, 4-Hour Workweek, etc...). What I have really learned is that I want to be more intentional about everything I do (Family, Time, Money, etc...). Part of this is removing my dependency on my phone, simplifying my life, and scheduling undivided time for the things that are important.
- Stop Complaining. I read this incredible book called A Complaint Free World . He talks about the power of Not complaining. This has really resonated with me.
- Blog Twice Per Month. OK This time I mean it (1 down, 23 to go! )
- Read 5 books. Arbitrary amount I know, but I need something measurable.
That’s it. Here’s to a healthy and productive 2016!
Feel free to link me to your 2016 goals blog posts in the comments.
28 Jul 2015
It’s late, you have been hacking all night to get the client a build. Finally, around 2:30 am, you hit submit and publish something to the client and go to bed. When you wake up in the morning, the first thing you see in your inbox is an email titled “Completely Broken!!1!”.
How could this be? You stayed up late, you hacked, you tested and you sweat over this build to find that it crashes for the client when they try to do something obvious.
As developers, we often can’t see the forrest through the trees. What this means is, we get so deep into the code working on a new feature or fixes that we often don’t notice when we break things. This doesn’t mean that we are bad developers, it just means we think differently about development. It also means we can’t personally handle everything.
However, from a client’s perspective, failures like this can really tarnish your brand. They start to get the impression that you are unprofessional and even worse, start to doubt your abilities as a developer.
QA (short for quality assurance) is an idea that someone other than the developer tests the build before the client ever sees it. These people are responsible for
- Regression testing (as in the scenario above)
- Generating a test plan/matrix
- Ensuring parity (if needed) between multi-platform applications
If the QA team is doing it’s job, the client won’t every see these obvious failures mentioned above. This can greatly improve the client’s perception of you/your team.
OK, QA sounds great, how do I get started? Well, it’s actually relatively simple. First off, I assume you are doing some flavor of agile, and hopefully logging tickets for each task. If not, you should (even if you are a one man show). Here is a rough flow that my team follows:
- Developers determine which tickets to work on for the current sprint
- Developers complete a ticket and move it to a “dev complete” column in the task manager (Jira, Trello, Pivotal Tracker, etc…)
- Developers deliver a build internally
- The QA team takes the build and goes through their testing matrix to check for regressions.
- If a regression is found, a bug ticket is created for the responsible developer
- New features are added to the QA test matrix and tested
- If the feature has bugs or doesn’t work as intended, the ticket is rejected and pushed back to the developer
- Once everything passes, the build is green-lit to be sent to the client (usually one build per sprint)
Like anything, you may develop your own version of the above, however this should be a detailed enough outline to get you started.
In my experience, clients will generally give you some pushback when you say that you are billing them for QA hours. They will say things like “It’s OK, I can test the build myself.” or “I understand, things won’t be perfect. We will through this together”.
While this all sounds good at the surface, the fact of the matter is, it almost always will end unfavorable. The client might have some level of tolerance early on, but as you start sending them more and more builds, each potentially missing/breaking features, they will become less patient. I have seen this happen plenty of times even with the most tech savvy of clients. Here are a few ways you can build QA into your billing process:
Add it as a line item
This is where you will most likely see the most opposition. Make sure to explain to the client that their time is valuable and you don’t want to waste it. Also, ensure that the cost of QA is drastically less than the cost of engineering or you will get questions like “Why am I paying you full price to test?”.
Be sure to tell the client that QA is just part of your team’s process. You simply don’t operate any other way as you know that this is the best approach for both parties. Hopefully, this will establish your expertise in the domain and the client will respect you for that.
Bake it into the cost of engineering
Often times, you may not bother with too many line items. You may just have something like Engineering $200/hour. When/If the client gives any pushback about cost compared to other shops, simply inform them of all they are getting inside of that hour (Engineering, Consulting, QA, Project management, Office management, etc…). It actually works out to be a much greater value for them than paying say $125/hour for a “code monkey”.
I absolutely believe that QA is crucial to the success of any software agency or freelancer. Not only does it allow you to come across as more professional, it also helps keep you sharp as a developer. While I’m not suggesting QA is a silver bullet (I still believe in Unit / Automated testing), I feel that everyone should at least have some layer baked into their process.
07 Apr 2015
There is a familiar phrase that I hear all too often when a client comes to me with an existing application. It goes something like this:
“Our team spent quite a bit of money on our application and we don’t want to ship it. We are not proud of the product.”
It blows my mind that many developers and development teams are still in business given the poor quality of products that I see getting churned out all of the time.
When I encounter these types of situations, I immediately know that the team (or individual) behind them is much more interested in a ‘quick buck’ instead of the longevity of their company. Poor quality in software is directly related to cutting corners.
A few examples of cut corners:
- Using inexperience developers without proper guidance. I am all for hiring ‘staff’ level developers, however, they must be properly mentored and trained so that there is no compromise on quality. If you must compromise on something, compromise it on time.
- Outsourcing the project without proper guidance. Although I don’t prefer outsourcing given the communication challenges, I am not opposed to it. There are plenty of talented individuals all over the world. However, given the varying degree of abilities and communication issues, one must not rely 100% on an outsourced team to ship a product.
- Not following coding standards/guidelines. This could be things such as: not commenting code, not testing, not leveraging a QA team, or simply writing “smoke an mirror” code.
I can usually identify immediately which of the above applies after spending a few minutes with the code. In fact, I have built much of my business around saving these types of projects.
So I urge you, although it might cut into my market share, *please *build something you are proud of. This is not only the right thing to do, it is also **critical **to your future success as an independant software developer.