Before I started down this professional path when I was 22 I had a fascination with salary jobs. A job that paid me when I was sick and gave me vacation and personal days, with that mythical 401k thing and the other perk “insürancé” (whatever that was), seemed like a worthy goal. In my family, hourly work was the name of the game for everyone so salary jobs were always put on a pedestal alongside, of all things, government work (a future in the DMV could have been mine!). Seeing the pain involved in simply living as a baseline really influenced a salary job to become my goal early.
With only a few exceptions, all through college (and a couple years after) I worked as either a waiter or pizza delivery driver, and sometimes both at the same time just to make ends meet. Like everyone else in similar positions, if I got sick or injured, or went on vacation, or my car broke down and I couldn’t make it in to work, or went home early for an emergency or doctors appointment, I didn’t get paid. It really reinforced my motivation during school to be honest.
The precariousness of this dynamic bothered me a great deal. But, being in college and working towards a better tomorrow, I had confidence it was temporary and that I would eventually gain one of those sweet, sweet, salary positions everyone kept talking about.
But when I did eventually get my first salary job I realized very quickly that what I imagined and the reality were two very different things. Yes, there were vacation days and sick days aplenty. (Well, ok, not “aplenty”, but I got a few of each and that was great at first.) And, yes, if I had a doctors’ appointment or had to go home early for any reason I’d be paid for the whole day.
The rub, of course, is that whether I worked 40 hours or 100 hours I only got paid for 40. And being a web developer, especially at that early level, a 40 hour work week is just rare.
At first, this was an easy thing to accept. Fresh(ish) out of my internship, and feeling like I’m starting to build “something”, I was all about the team and the company and “getting the job done”. Ra ra ra and all that. I recall being very sympathetic about issues requiring sacrifice in order to “save the day” and “do my part” for the team. Essentially, for what amounted to free more often than not.
Now, this may work wonders for other salaried vocations, I have no idea, but programmers, web developers, sysadmins, and designers, we’re all knowledge workers and working like this is straight demoralizing. Our jobs require thinking, planning, strategy, and then implementation and integration. And it’s the planning and strategy parts that really screw one over in this line of work.
Looking back on it, it was the teamwork part that was especially motivating and conflicting to me personally. How could I leave my team to continue working on our common goals, all wrapped in their suffering and pain, while I go off and avoid it? I couldn’t rationalize it.
So working tons and tons of hours became a part of my world. A part of my reality. For years and years this is how I looked at the job of web development and programmer at agencies.
It took me a few years to realize the truth: there are no “our” goals. Hell, there is no “us”. Not really. It’s been my experience that it is the rare company that actually cares for their employees with the same loyalty they demand from their employees. This is just what business is (at least in America).
Now, before anyone calls me cynical; I don’t begrudge that. Not even a little. In fact, embracing that is incredibly liberating. It’s about money. In the end, no matter how much you love your team or what you do or how much is taken personally, having a job is still all about making another dollar for someone else who’ll give you your piece.
Which, in a nutshell, is why I’m a freelancer/contractor/mercenary now. But, I no longer have the safety net of a salary so I have to get creative with billing and income. Since I get asked asked all the time how I can remain independent without being broke I thought I’d go over the “hows” of my income as a contractor.
For my main contract clients, I bill either hourly, which I’ve discussed in the past, or with a retainer, which is fairly new to me but tends to work out nicely (tends to). Then, of course, there’s also the supplemental income from ExpressionEngine add-ons, core customization requests, and, lately, stand alone extensions to my own add-ons.
Frankly, I love hourly. I’d work 168 hours a week if I could get paid for every single one of them. Scope creep, management incompetence, team or hardware failures, complete and total process failure? I couldn’t give a single damn about any of them. I’m being compensated for every minute of my time at a rate I agreed to.
The only real downside to billing hourly is that it automatically shrinks the pool of available clients I have access to. Some clients are just turned off by it, as an institutional rule, so I’m an automatic pass for certain projects. Still, speaking personally, losing out on projects because a client doesn’t pay hourly contractors has yet to hurt me in any meaningful way.
The other method, retainer, is new to me. With few exceptions though it appears to be working out pretty good. The basic idea is simple: a company “retains” my services and is guaranteed XX hours of my time a week/month/whatever for guaranteed YY payment.
For straight up retainers, this works out great. It’s the opposite of a salary position. 100% win for me, with the client taking all the risk and me making my rate for overages while still getting paid when I don’t work. It’s like free profit; I can really see why lawyers are fond of it.
There’s a new trend in retainer deals that’s come up lately though that changes this dynamic a little; retainer hour banking. Essentially, the idea is that hours don’t expire but roll over for later use by the client or contractor depending on the divide. For example, a client pays for 20 hours a week but only uses 10 hours so they have 10 more hours to use at another time. So long as the base retainer continues to be paid the hours stay valid for use.
On the surface, this appears to be a fair agreement. With straight retainers, the client runs the risk of taking a financial loss while the developer has little to no risk at all. Hour banking changes that in a more equitable manner. I really hate the adversarial style of business so if I can work things win/win for me and the client I’m usually all about it.
The big downside to hour banking is the imbalance that quickly develops just from the nature of web development in general. With most projects and tasks I’ve worked on, devs can burn through a retainer term really, really, quickly. Working two sixteen hour days in a row, doing research then design and then implementation, isn’t unheard of in this line of work so, with hour banking, a client can accumulate an unwieldy balance with little effort. Constant diligence has to be had to ensure things are kept in check. Because of that, I’m really not as big a fan of this compared to straight hourly or a normal retainer term.
Then there’s ExpressionEngine add-on development. Add-on development is a bit of a long game, so the income isn’t significant compared to client work just yet, but it does provide a nice cushion of income worth note. Erik Reagan has a great piece outlining the pros and cons of add-on development that’s worth reading, and while I agree with his position from an agency standpoint, for the individual dev I think add-on development is a nice side venture worth undertaking if you’re independent and able.
And not just ExpressionEngine; lots of platforms are extensible and have commercial add-on ecosystems. If you can hold down the rage, developing add-ons for Magento or WordPress are both viable, and supposedly, profitable, options. For those who want a little joy in their lives, I hear Statamic and Craft are the ones to watch.
The most obvious benefit is additional income but I don’t think it’s the most valuable for a contractor. Looking back on over 2 years of add-on development, I have to say the most valuable benefit I’ve gotten is the familiarity with the base platform. I know ExpressionEngine. When it comes to ExpressionEngine contracts, I have a nice advantage in being a known resource. My work is out there and some people even like some of them enough to talk about them to their clients. I’ve found it really helps with winning over the new clients or agencies.
The other side though is customization work. Initially this was specific requests to core aspects of an add-on that were so time consuming, or conflicted existing schedules, that customers would pay for the feature instead of waiting for me to get to it naturally. For example, Backup Pro having Rackspace Cloudfiles support, CT Admin Product reports, and Securit:ee’s Security Scanner feature, were all commissioned core changes from customers. Core changes isn’t significant income, but it’s notable because of the complete return in that the it’s possible to get paid to improve your product. Something about that just feels amazing.
But, after implementing extension hooks into my add-ons last year, most requests are done as stand alone and specific add-ons that sit side by side with the core add-on. I really like doing this type of work. With my normal client work, a big part is writing custom add-ons specific to their site but along with all the other parts of building a site that I generally hate doing, so this allows me to just come in and do just the fun part.
Make no mistake though; this is tons of work (and don’t get me started on the definition of a ton) but well worth it in my experience. If you’re thinking about throwing off the shackles of mainstream work though, and are concerned about how to make ends meet, this is a strategy that’s worked out well for me for a few years now with no end in sight.
If you want to learn more about billing practices and ExpressionEngine, be sure to check out Ryan Battles talk at this years ExpressionEngine Conference in Portland on October 14-15.