My Realizations about Software Consulting

I consume a lot of audio books.  Most recently, this habit led me to listen to a book by Allen Weiss, called Million Dollar Consulting.  The title yields the book’s premise in deceptively simple fashion: a guide to building a seven-figure-per-year solo consulting practice.  Sound crazy?  Two and a half years ago, when I went into business for myself full time, I would have thought so.  Now, it sounds pretty doable to me, if that’s your thing.

This isn’t to say that I have a million plus dollar per year consulting practice — just that I understand how someone could achieve what he’s talking about in a way that I couldn’t have back then.  Listening to this book gave me cause to reflect on my free agent journey, so I thought I’d write about that today.  (I know there are some who’ve wanted more of these posts anyway)

When I first took the free agent plunge, I had a fairly vivid picture of how it would work.  I was leaving a job running an IT department, and what I sought was a practice where I helped solve targeted technical problems for a portfolio of clients, rather than solving all sorts of organizational problems for a single entity.  I wanted both to diversify and to become more project-focused.

The Neophyte Techie Free Agent

Beyond that, I didn’t really have a firm grasp of the path to growing profit.  At the time, I assumed that technical consultants did what members of app dev groups did, but for much higher pay (due to transience and achieving better results).  That is, I might do a mixture of application development, architectural consulting, training, mentoring, troubleshooting, etc.

I’d start out charging, say, $100 per hour and then let supply and demand drive up my rates as I pleased more and more clients.  This, I reasoned, was the path to bill rates exceeding $250 per hour.  And, why not?  That seems to be how so-called app dev consultancies work, offering blended rates and billing out their principals and super-awesome-folks at $250/hour.

At the time, I remember chatting with John Sonmez of Simple Programmer.  He and I knew each other through the blogging community and through Pluralsight.  He’d made a similar career play a year or two earlier than I had, so I picked his brain about his journey.  He told me something quite memorable, in that it proved prescient, but was inconceivable to me at the time.  “I want to get away from trading hours for dollars.”  Huh.

Realizations

What I now understand, two and a half years later, is that the bridge from 9-5 life to what I do now (and he did then) requires as toll a total overhaul in thinking.  Since I can still remember my thinking then and have a good grasp on how it has changed, I’m hoping I can help you along the bridge, if you’re interested.

Bear in mind that “if you’re interested” acts as more than a polite qualifier here.  For the rest of this post, I’ll cover two realizations that I have had and how I arrived at them.  If my style of professional life interests you, then pay attention.  If my path doesn’t appeal, then perhaps just read with passing curiosity.  I offer insight into my own preferences — not universal truths about how everyone should make choices.

I should also note that I didn’t wake up one morning, sit bolt upright in bed, and realize that enlightenment had struck.  Rather, I came to these realizations gradually, through trial and error, experience, introspection, and some amount of dumb luck.  Insight isn’t always the result of careful deliberation.

Freelance Programming Establishes Low Status

As a neophyte free agent, I thought the free agent hustle involved getting people to pay you a lot to code.  Now I realize that writing code by the hour puts an unyielding governor on your income.  I speak to this anomaly extensively in part 4 of Developer Hegemony, but suffice it to say that the world views programming more as labor than knowledge work.  And people don’t pay the highest rates to laboring grunts.

Over the years, I’ve seen countless proposals and statements of work for software development.  Invariably, the actual software development commands the lowest hourly rate.  Planning the project, creating the “architecture,” plotting organizational strategy, training people, and creating user experiences all apparently command more market value than the mundane business of cranking out code.  Thus project managers, architects, managers/management consultants, trainers, and UX folks all command higher rates for low hour activities that exist at the periphery of the core development effort.

To make matters worse, economics drive perception.  It isn’t just that developer activity being more common and lower wage results in smaller payouts.  It also results in lower regard.  Developers know where to put for loops and little else — if you want intelligent people to help your company make or save money, that’s an upsell.

Having a reputation for writing code thus limits not only a free agent’s effective hourly rate but also his credibility.  Even for highly specialized, highly niche developers, the same dynamic holds at a higher rate.  As a former CIO and IT management/strategy consultant, CIOs, dev managers, and boards don’t bat an eye at engaging me as a peer.  As a freelance software developer, they’d tell some line-level architect to give me a coding test and probably never talk directly to me.

Realization: I Avoid Being Paid to Code

“Sometimes, I think about giving it all up and going back to coding.”  Managers and tech executives say this almost as often as they talk about having trouble finding free time in their Outlook calendars.  I think of it as a half-honest, half-signaling activity in the same way that a 35-year-old with four children and a minivan reminisces about hard drinking nights in college.

For me, though, getting back to full time programming is a legitimate career goal.  The catch?  I won’t do it for a wage or hourly contract.  When I make it back to full time programming, it will be in the pursuit of building my own products or when money is no longer important and I’m in it for the love of the game.

I often hear developers wrestle with the conundrum, “how do we know when quality is good enough to ship, and when we’re just being perfectionists?”  If you’re a wage laborer writing software, that’s a legitimate question of professional ethics.  If you’re building your own empire, the question reduces to a simpler consideration: “can I afford financially to prioritize my pride?”

Setting aside images of future bliss, however, the outlook on wage programming remains clear to me.  Writing code on someone else’s hourly dime is a doubly losing proposition.  It establishes you as a low-status, tactical thinker and it caps your potential earnings.  I don’t believe this will always be true (indeed, Developer Hegemony is about how to change this dynamic), but until it ceases to be true, I will generally avoid hourly coding.

Lack of Measurable Goals Establishes Pseudo-Employment

It took a long time for me to realize (sadly) how important it is to avoid being pigeon-holed into development.  (Ironically, it’s doubly hard to avoid status erosion if you’re good at programming).  It likewise took me a similar amount of time to arrive at realization number two.

When you dive into the world of being a free agent, you have visions of never finding a client.  I remember sending emails to a whole bunch of people in my network saying, “hey, I’m going to be doing freelance stuff now, so let me know if you need anything!”  I heard crickets (and deservedly so, since this was an obtuse thing to do — if you’re interested in better ways to find work, I can write about that separately).  As a result, when I did find work, I tended to seize onto it like a drowning victim to a life preserver.

In these early days, I imagined that ultimate freelance success would be to find, say, four clients for whom I did 10 hours per week of work, and to have those arrangements stand in perpetuity.  In this fashion, I’d have both stability and steady work, indefinitely.  (I failed to recognize that this differed little from being a remote employee but with more paperwork.)

At this point, I would have viewed a two-month engagement toward some goal as a consolation prize.  Sure, I would have work, but at the end of the engagement, I’d be right back at square one, having to start all over.  No, I reasoned, the best thing was to engage in open-ended contracts.

Realization: I Don’t Take Projects without Predefined Success States

Looking back now, I still get it.  Until you’ve secured work a bunch of times, your default state will be to think that work is hard to secure.  Two and a half years later, I’ve found a lot of work.  I have the benefit of hindsight to show me that one can have a measure of security even with limited duration engagements.

In fact, I now avoid open ended engagements.  Why?  Well, because open-ended contracts become indistinguishable from wage labor, and I got out of that game for a reason.

Most trivially, consider the 40-hour-per-week, open-ended contract.  The only thing that separates this ‘consultant’ from a wage laborer is the name of the tax document.  But even with fewer hours or more flexible agreements, the open ended arrangement translates to “come do some work for us indefinitely, finding ways to be awesome and help us out.”  That’s the charter of an employee.

I now refuse engagements that smell like open-ended arrangements.  In order for it to make sense, my clients and I need to come to agreement on a simple mad lib: “We will both know and agree that the engagement has ended successfully when ___________ is true.”

This could apply to me coming to do two weeks of onsite training or some other fixed duration concern.  Likewise, it could be fixed duration, but with a goal, like helping a client hire three new developers and an architect.  But in all cases, we talk up front about how we know it’s done.

I’ve come to the opinion that this outlook is table stakes for calling yourself a consultant.  Consultants come, help clients fix problems, and then go.  They don’t show up and hang around looking for problems to solve until someone boots them out.

The Future of Software Consulting

As I said at the outset, I’m explaining realizations I’ve had about myself and how I prefer to work.  I’m not saying that there’s anything wrong with wage employment, coding for someone else, or open ended engagements.  That doesn’t work for me, but a healthy workforce requires diversity of preference.

Still, I realize that some of what I’m saying here might seem cynical — particularly the bit about programming as a low status endeavor.  And, I suppose that actually is cynical.  But I feel cynical not toward programming or the people who do it, but toward the workforce that treats it this way.

It’s 2016, and yet our corporate structures and practices largely hold over from the days of Frederick Taylor, 100 years ago.  Programmers do work that is regarded as low status not because the work should be regarded as such, but because we have yet to leverage our dominance of the economic climate to correct that view.  But don’t worry, that’s coming.

I earnestly believe that within 10-20 years, software developers will have seized substantial control over our own destinies when it comes to preferred modes of working.   So, stay tuned, and enjoy the ride.  It’s a bummer that things are the way they are, but they won’t be that way much longer.