The Key to Becoming a Software Consultant

Recently, I made an idle threat on Twitter (shown below).  I was thinking of creating some content along the lines of how to go from being a software developer to a software consultant.  People ask me about this all the time, and it makes for an interesting subject.  I was also flattered and encouraged by the enthusiastic response to the tweet.

I’ve been getting that book writing itch again this week. Thinking about a guide for developers on how to become consultants.

— Erik Dietrich (@daedtech) June 21, 2017

I’m still mulling over the best delivery mechanism for such a thing.  I could do another book, but I could also do something like a video course or perhaps a series of small courses.  But whatever route I decide to go, I need to chart out the content before doing anything else.  I could go a mile wide and a mile deep on that, but I’d say there’s one sort of fundamental, philosophical key to becoming a software consultant.  So today I’d like to speak about that.

Software Consultant, Differentiated

I won’t bury the lede any further here.  The cornerstone piece of advice I’ll offer is the one upon which I’d build all of the rest of my content.  You probably won’t like it.  Or, you’ll at least probably think it should take a back seat to other pieces of advice like, “be sympathetic” or “ask a lot of questions” or something.  But, no.

Don’t ever let would-be consulting clients pay you for code that you write.

Seriously.  That’s the most foundational piece of your journey from software developer to software consultant.  And the reason has everything to do with something that successful consultants come to understand well: positioning.  Now, usually, people talk about positioning in the context of marketing as differentiating yourself from competitors.  Here, I’m talking about differentiating yourself from what you’re used to doing (and thus obliquely from competitors you should stop bothering to compete with: software developers).

Let me explain, as I’m wont to do, with narrative.

Leonardo Da Vinci: Renaissance Plumber

By any reckoning, Leonardo Da Vinci was one of the most impressive humans ever to walk the planet.  Among his diverse achievements, he painted the Mona Lisa, designed a tank, and made important strides in human anatomy.  But let’s say that, in a Bill and Ted-like deus ex machina, someone transported him 500 years into the future and brought him to the modern world.

Even someone as impressive as Leonardo would, no doubt, need a bit of time to get his bearings.  So assume that, as he learned modern language, technology, and culture, he took a job as a plumber.

Let’s assume that you happened to have a leaky sink faucet, and you called Leonardo’s plumbing company for help.  They dispatched him forthwith to take a look and to help you out.

So Leonardo comes over and, since he’s Leonardo, figures out almost immediately that your supply line has come slightly loose.  He tightens it, and you couldn’t be more pleased with the result.

Leonardo, Ignored

Encouraged by your praise, Leonardo then gets a bit of a twinkle in his eye.  He does some mental arithmetic and tells you that could actually cut down on your water bill by about 15% if you adopted a counter-intuitive way of cleaning off your dishes after meals.  He proceeds to tell you how that would work.  And, while he’s at it, he points out that the painting print on your kitchen wall isn’t a good match for the paint in the room.

And do you know what you do in response to the genius of Leonardo Da Vinci teaching you a better dish washing scheme and helping you with your art?  You smile, humor him, and think to yourself, “just fix the sink and get out of here.”  And you’re absolutely right to do that.

Why?  Because you have no way of knowing that he’s Leonardo Freakin’ Da Vinci.  You just understand that you hired someone to fix a sink, and that someone is now giving you unsolicited advice about washing your dishes and decorating your house.  You hired him to perform labor, and instead (or in addition to), you’re getting his opinions about your life.

Software Developer, Ignored

Anyone reading this that has spent time as a professional software developer can probably relate to my channeling of Da Vinci.  You understand the better outcomes your company would have if you’d ramp down tech debt.  You can easily see that management’s waterfall ‘methodology’ is ineffective and misery-inducing.  And, while you’re no expert, you even know that the company’s branding and sales strategies are ineffective.

You offer constructive feedback, but nobody listens.  You’re Da Vinci, ignored.  And I’m not patronizing you.  You have to be smart to write software for a living, and in every shop I’ve ever visited, the software developers had good ideas that extended far beyond the boundaries of an IDE.  And, usually, management humored them or else flat out ignored them.  You could chalk this up to familiarity breeding contempt, but it’s really the positioning that I mentioned earlier.

Management hired you to perform the labor of writing code.  Your unsolicited opinions are not part of that equation.  Because you’re in high demand, people smile, nod, and humor you.  But they don’t care.  That’s the life of a software developer.  File your suggestions in the little bin, on the ground next to my desk with a “suggestions” label taped over the “trash” label.

Would-Be Software Consultant, Ignored

Let’s say that you tire of this at some point.  You decide you love the industry and that you love software, but you want more influence.  Management isn’t for you, so “consulting” it is.  Maybe you hang out your shingle to freelance, or maybe you go work for a software “consulting” firm.  Now, it’ll be different.  Now, people will listen.

And then, to your intense frustration, it doesn’t turn out that way.  Even though you have “consultant” in your title and charter, people still humor you and say, “whatever, buddy, just code up the spec.”

What gives?  Well, a big part of the problem lies in the dilution of the term “consultant” in our line of work.  Everyone at your client’s site that doesn’t have a W2 arrangement with that client is a “consultant,” whether they personally advise the CIO or whether they lock themselves in a broom closet and write stored procedures.

And, to make matters worse, every firm that does custom app dev and calls it consulting positions themselves in an entirely predictable way.  “Oh, heavens no.  Our consultants aren’t just coders — they write code AND provide thought leadership and advice.”

That’s so utterly expected that some clients would probably find it refreshing to hear one of these shops or people say, “nope, we just turn specs into code.”  Thank goodness.  I finally don’t have to listen to the plumber talk about my choice of wall decorations.

Positioning Like You Mean It

So let’s take an honest look at the software consultant’s situation.  All that “consultant” really tells anyone for sure is that you do work for someone that doesn’t send you a W2.  But, if they play the odds, it tells them that you write code for someone that doesn’t send you a W2 and will offer a lot of opinions, whether anyone wants them or not.  The stock software consultant persona and thus default positioning is then “opinionated, above average developer.”

Now the people interested in my prospective book or course are people that actually want to be consultants.  Firms don’t pay consultants for labor (or code); they pay consultants for their opinions.  So, here’s the rub.  If you introduce yourself as a software consultant or someone else introduces you that way, your default positioning is “coder.”  But, to achieve your objective, you need to position yourself as an actual consultant, getting paid for advice.

While many subtle options exist to nudge yourself in that direction, you have one foundational one.  Don’t let your clients pay you to write code.

In a world where every software developer writing code for another company is a “consultant” you can position yourself as an actual consultant by not writing code for pay.  Nobody confuses you with a pro coder then.

Medicine as a Metaphor

Jonathan Stark, of Ditching Hourly and the Freelancer’s Show, has a great metaphor to help you understand the positioning concept.  And I’ll use it here to drive home a major differentiation between consulting and laboring (i.e. writing code).

He talks about four phases of solving problems for companies.  Those include diagnosis, prescribing a cure, application of the cure, and re-application of the cure.  Software developers and most so-called software consultants involve themselves almost exclusively in phase three: application.  But that’s a pretty low leverage place to be.  Consultants exist almost exclusively in phases one and two: diagnosing and prescribing.  They let laborers take care of phase three and even lower status laborers take care of phase four.

Think of it in terms of other knowledge workers.  You go to the doctor with an ailment, and the doctor figures out the ailment and prescribes medicine.  But if that medicine involves rubbing stuff on the bottom of your feet 5 times per day, he doesn’t also handle that — it’s below his pay grade.  You do that yourself, or you hire a masseuse or something.

When you write code as a software “consultant,” you tell people that you’re in the business of diagnosis and prescription.  But when the rubber meets the road, you spend almost all of your time slathering stuff on people’s feet and talking at length about (“consulting on”) the best ways to slather.

Now, imagine an industry in which diagnosticians and slatherers alike all called themselves doctors.  When you needed a diagnosis, you’d start to look reflexively for people without goop on their hands in order to tell the difference.

Caveats

First of all, let me clear something up immediately.  I can practically write the comment myself.  Someone is going to read this and say, “well, I’m a consultant that writes code for my clients and they actually asked me whether they should adopt Scrum or not and then listened.”  Yes, I believe that in the same way I believe that management does sometimes listen to staff software developers’ opinions.  It happens.  But it’s a far cry from you being there only to tell them whether or not to adopt Scrum.

Secondly, you can write code in a consultative capacity.  Coaches and trainers make excellent examples.  Notice that I said not to let people pay you for code that you write.  Companies don’t pay trainers for the code that they write, but rather for the service of showing their team how to write code.  As a rule of thumb for differentiating, ask yourself whether the client depends on you to code something intended for production.  If the answer is yes, you’re slathering foot goop and not diagnosing.

And, finally, I won’t dispute that some people may walk this line with more than ephemeral success.  Maybe everywhere they go, they roll up their sleeves and crank code all morning, only to then go into the CIO’s office and provide strategy advice.  I’ve never actually seen that or anything close to it, but it could happen.  Or, maybe even more likely, someone consults for some clients and codes for others.  Whatever the arrangement, some people might succeed in perpetually walking the consultant-coder line.  And, good for them.  But what I can tell you is that this is the exception and not the rule.

There’s an Awful Lot More to Consulting, But Here’s Your Start

As I mentioned in early in the post, I could fill a book or course(s) with information about how to succeed as a software consultant.  Going from software developer to software consultant seems kind of straightforward, but that’s really fools’ gold.  It’s superficially easy if you accept the extremely loose definition of consulting, but not if you seriously want to get paid for expert opinions, diagnoses and prescriptions instead of for writing code.  Then you have a good bit of learning and skill acquisition ahead of you.

So why, of all things, do I pick avoiding writing code as foundational?  Well, as I’ve said all along, positioning yourself is critical, and that’s your single best piece of positioning.  In order to get paid for diagnosing, you need someone asking you for a diagnosis and not asking you to slather stuff on their foot and just call that diagnosing.

But there’s an even subtler reason for the emphasis on not coding, as well.  Writing code is satisfying, fun, and extremely marketable.  And so finding people to pay you to write code is tantalizingly easy.  They need your programming skills so badly, they’ll probably even call you the “CEO of teh codez” if that’s what you want to be called.  You have a ready-made crutch.

Refusing to write code for clients means forcibly removing the crutch.  Doing this, you’re like a non-native language speaker that flies to a foreign country and practices learning by immersion.  You have no crutch, and no choice but to figure it out.  You can write code for fun, in your spare time, and to support your practice.  But if you want to get serious about consulting, stop slathering so that you can start diagnosing.  Don’t let ’em pay you for your code.

And, by the way…

By the way, if you liked this post and you're new here, check out this page as a good place to start for more content that you might enjoy.  You can also sign up for my mailing list below to check out a free set of chapters from my book.

Want more content like this?

Sign up for my mailing list, and get about 10 posts' worth of content, excerpted from my latest book as a PDF. (Don't worry about signing up again -- the list is smart enough to keep each email only once.)

Get the content!