If You Want to Matter in the Software Industry, Stop Being a Laborer

Alright, first things first.  I’m going to do a bit of housekeeping.  My apologies for the sluggish performance of the site lately, and the occasional 500 errors you may have noticed.  My hosting company’s physical machine has been having some issues and they’re trying to figure out whether they can fix it in-situ or whether I need to take an outage while they migrate me to another machine.  Also, my apologies for missing reader question Monday.

Fate has conspired to sentence me to a couple of poor nights of sleep in a row.  So I don’t really have the energy for a rant.  Instead, I’m going to go the more zen route and continue with the “developer to consultant” series.  Today, I’m going to focus on the mindset shift you need in order to go this route.  You need to stop being a laborer.

The Phases of Problem Solving

In a post where I first mentioned this idea of guidance on how to transform yourself into a consultant, I referred to the phases of problem solving.  Roughly speaking, these are the following.

• Diagnosis of a problem.
• Prescription of a therapy.
• Application of the therapy.
• Re-application/maintenance of the therapy.

When you’re sick, you go to the doctor.  The doctor furnishes a diagnosis and writes you a prescription, and then exits the equation.  An unskilled laborer (i.e. you) then applies the therapy of taking the pills.

A similar concept applies in other sorts of knowledge work.  A lawyer, for instance, figures out which precedents to cite and then hands it over to a law clerk to write up or to an admin to make copies.

Or take a tax accountant.  The accountant herself figures out whether you should file as an S-Corp or pass through the taxes and then turns the paper work over to a less skilled assistant.  You get the idea.

But to tell you how this relates to us and to software, I don’t want to compare us to these people.  I want to compare us to an arch-criminal.

Winston Wolf, Master Consultant

In the movie Pulp Fiction, a couple of gangsters named Jules and Vincent are driving with another guy, Marvin in the backseat.  Gesturing with his gun during conversation, Vincent accidentally blows Marvin’s head off, creating quite a horror show in the car, right in the middle of a public roadway in broad daylight.

Vincent and Jules, hardened criminals though they may be, panic and duck into a nearby associate’s house, and call their boss who sends his “cleaner” — one Winston Wolf.

Wolf is a consultant.

You can watch the (graphic) scene here if you want, but suffice it to say Wolf helps.  He quickly and efficiently sizes up the situation, diagnoses all problems, and lays out a solution.  He then dispatches Vincent and Jules to execute the details of the solution (“apply the therapy”.)

Despite some grousing from Vincent, who doesn’t like being told what to do, Jules and Vincent oblige, and they set about the grotesque tasks of cleaning viscera out of the car, placing liners over the seats, etc.

In this episode, Wolf’s diagnoses and prescription are valuable.  The cleaning/scrubbing/etc tasks of execution are important, but only valuable because of the circumstances.

Without Winston, Vincent and Jules go to jail.  Without Vincent and Jules, someone else could always do the labor.

Programmers as Vincent and Jules

So why this gory analogy?  Why not doctors, lawyers, or accountants?

Well, because there’s a really interesting parallel between our world, as programmers, and this one.  Jules and Vincent superficially seem valuable because of a labor scarcity.

Think of it this way.

The participants in this criminal conspiracy are in something of a pickle.  They can’t exactly call a local cleaning service or send out a task on Fiverr to get what they need.

The labor pool is extremely small for people to whom they can delegate execution of the gruesome cleaning tasks.  So they wind up (and bear with me here) paying hit men, who presumably command a high hourly rate, to wash a car.  This washing is disproportionately expensive because of a labor shortage, but not intrinsically valuable.

This is how programmer labor works.

The valuable part of software happens in the recognition that some kind of automation can create a lot of revenue or savings (diagnosis) and creating a working plan to build that automation (prescription).  From there, the execution is just labor, but it’s expensive labor because the demand for programming far outstrips the supply.

But don’t let that fool you.  It’s still commodity labor, like wiping down the inside of a car.  As an aspiring consultant, you need to stop being an overpaid hit man and start, instead, being the Wolf.

The Irony of Programming as Grunt Labor

Programming isn’t as hard as we make it out to be, when we turn it into a hobby with asinine “coding wars” competitions and such.  But nor is it easy.

Programming is knowledge work and it requires the amalgamation of complex and formidable mental skills: creating useful abstractions, sequential logic, deductive and inductive reasoning, etc.  We’re not punching above our weight in a room with doctors, lawyers and accountants.

So how is it that, unlike all of them, we manage to turn our knowledge work into commodity labor and ourselves into low-influence grunts?

Well, as I said, I’m not in rant mode today, and going into that would require a rather lengthy, ranty post.  (If you want to see me speak to that in a lot more detail, check out my book, Developer Hegemony.)  But let’s just say that a lot of it ties heavily into our assumption that being a “real” programmer means hyper-focusing on writing code and doing little else.

To put it another way, we never bother to think about diagnosis and prescription.

Why are we building the software we’re building?  How does it save someone money?  Will it contribute to a product that will have product-market fit?  And so on.  For the most part, only two types of people with programming skills think about these questions.

• Entrepreneurs (“technical founders”).
• Consultants.

And, it just so happens, this series is about how to become the latter.

Your Next Task: Brainstorm Ways to Stop Laboring

If memory serves, Winston Wolf didn’t do any of the scrubbing.  Could he have?  Sure.

But if someone were value-pricing that whole affair, I think they would have given the Wolf the same (enormous) consultative fee whether he did that himself or delegated it.  That should be your model as you start to turn yourself from grunt to consultant.

What could you do that involves only diagnosis and/or prescription?  And I don’t mean “lay out a plan to speed up database calls by 40%.”  What diagnoses/prescriptions could you offer that someone would pay for?

Often when mediocre or disinterested developers “sell out” and start pursuing the project management to management boss track, they’re subconsciously figuring out exactly what I’m saying here.  The real money isn’t in mastering your 12th tech stack, but in prescription and diagnosis.  Low hanging fruit involves activities like discovery and project road-mapping, but you can get a lot more exotic and unique than that.

But I’m trying to fight hard against the world we currently live in, where the higher value activities and writing code are, for most staff software developers, mutually exclusive.  These things should be complimentary, or even integral.  

Writing code is just automation, and automation is the art of making things more cost effective.  Who better to make diagnoses and prescriptions than someone well versed and experienced in automation.

So look around you at your office, and practice identifying as many “Wolf opportunities” as you possibly can.  You don’t have to pursue all of them or even any of them.  Just start seeing them, and thinking about which ones could fit with and comprise your positioning.

There are consulting opportunities all around you if you just learn how to look for them.