What Do You Know That People Would Pay You For?

I actually started this post last week, in what was shaping up to be a long one.  Instead, I decided to spin the lead-in off into its own post about staff augmentation.

In that post, I covered a decent amount of ground, but I’d like to focus in on two main points about the software industry.

1. We have a curious habit of calling ourselves “consultants” when we’re not.  In other words, our industry is perhaps the lone industry where we refer to labor as “consulting.”
2. The main determining factor in what we call software development engagements is who manages the software developers.

This lead up, expounded upon mainly in the previous post, leads to an interesting question.

If Software Development is Knowledge Work, Why Do We Act Like It’s Labor?

I talk frequently on this blog about knowledge work and surrounding concerns.  Here’s a good working definition of knowledge work.

The term “knowledge worker” was first coined by Peter Drucker in his book, The Landmarks of Tomorrow (1959). Drucker defined knowledge workers as high-level workers who apply theoretical and analytical knowledge, acquired through formal training, to develop products and services.

…

They include professionals in information technology fields, such as programmers, web designers, system analysts, technical writers, and researchers. Knowledge workers are also comprised of pharmacists, public accountants, engineers, architects, lawyers, physicians, scientists, financial analysts, and design thinkers.

Software development certainly seems to fit the bill.  I mean, it’s literally mentioned repeatedly in this definition.  And yet, perhaps uniquely among all of these vocations (except maybe technical writing), software developers are paid for what we do with our hands, rather than what we know in our heads.

Don’t believe me that this is a curious diversion?

Then why does it find its way past even how people bill for our work and into our job titles: “architects” to do the “big picture thinking” and software developers (laborers) to bang out code?  Or into our self-selected metaphors, such as the strained guild concept, where we’re not experts offering diagnoses, but “craftsmen” building digital cathedrals or horseshoes or whatever?

Alright, So Maybe We’re Sold More as Pairs of Hands than Brains… So What?

You might look at the list of cited professions and think that it makes sense.  I mean, doctors diagnose things and pharmacists trade in prescriptions.  Engineers and architects create plans, which is like a different flavor of prescription.  Lawyers, analysts and CPAs, you might argue, kinda sorta perform a sort of labor (though they mostly delegate the menial bits to underlings and stay in the realm of diagnosis and prescription).

But we, software developers, we build things.  And we take pride in building things.

And what’s wrong with that?

Nothing is Wrong with It, But It Has a Cost

Well, first of all, as someone who loves the feeling of bending source code to my will, I’ll say that nothing at all is wrong with that.  I love writing code.  I also love woodworking, home, improvement, and cooking, all of which involve flavors of building a thing.

But here’s the rub.

I love doing all of those things.  But I don’t opt to do them for money, and neither should you, if you want to become a consultant (or be a knowledge worker).  In that post about consulting, I point out that consulting (and, I would add, real knowledge work) occurs in the prescription and diagnosis phases.  The application of therapy and re-application of therapy are relatively brainless labor that tend to fall to people with much less expertise.

Being a Laborer (Pair of Hands) is Career- and Influence-Limiting

I view this as something of a professional travesty.  You have to be intelligent and knowledgeable to write software well.  People that do well in software development could easily do well in these other fields.  So why do people pay so little attention to what we know, and almost exclusively to what we do and how we do it?

• You pay doctors for a diagnosis and pharmacists for prescriptions and then you apply the cure.
• You pay an architect for a blueprint and then hire laborers to build the building.
• But with software developers, you generally pay them nothing for “discovery” and “planning,” which they give for free in hopes that you’ll choose them to toil for you.

That’s absurd, and it doesn’t have to work this way.

Receiving money in exchange for labor is a reasonable thing to do and, with highly skilled labor, it will earn you a handsome wage.  But it’s limiting.

1. There’s a hard upper bound on the rate for software development, both as a wage employee and as a free agent.  Most software labor is commodified, meaning it’s a race to the bottom on price.  (Companies interview a bunch of people just like you to find which one will give them the most labor for the same pay.)
2. Labor isn’t synonymous with influence or decision-making.  You won’t ever call the shots when you’re a laborer — even about your own labor and how you do it.  This is why so many frustrated developers lament that management won’t even let them unit test — a preposterous bit of micromanagement.

And there’s no reason that you can’t flip the script here.  You can create situations where people pay you for your knowledge, rather than your labor.  You can be a brain instead of hands for hire.

Already, You Know Things that People Would Pay For

It might be hard to shake out of the labor mindset, so let’s start with an easy example.  You already know things that people will pay for.

I do a little bit of programming for our content agency, Hit Subscribe, which includes building features into an ASP MVC line of business app to make life more efficient for the staff.  I do some work on it maybe once a week.  This means I have some rust to shake off.

So little questions pop into my head that I have to research.  “How do I change the connection string for an entity framework database migration” or “what’s that app.config setting for the yellow screen of death in prod?”

I would literally pay for these answers to save my own time.  Not much, but I’d pay.  And some of you probably know them.  Sure, I could go onto Stack Overflow or something.  But I’m not really interested in why Joe26239 cast a close vote or whatever — I just want a little piece of knowledge.

This is small, and it’s hardly a business model.  But it demonstrates that you know things that people would pay for.

But You know Things with No Coherent Theme and that Many Other People Know

Now, before you run out to start your own “here’s that YSOD setting in web.confg” consulting business, understand something.  As a generalist programmer, you have mostly a random hodgepodge of knowledge.  There’s no rhyme or reason to it beyond which story cards some project manager assigned you.

That’s true of very discrete pieces of knowledge, like the ones I’ve mentioned.  And it’s also true of technical decisions and opinions.  For instance, “should we use an ORM or not” is a question for which everyone on your team has some answer.  Whose is the best on your team?  Nobody will ever know because management will just ask the person who has been at the company the longest.

So You Need to Start Refining What You Know

So if you want to start thinking like a consultant, you need a better strategy than amassing the endlessly orthogonal knowledge of the generalist.   You need to specialize somehow, becoming the “whatever person” for some undetermined “whatever.”

I’d suggest starting with something that both excites you, and about which you have a lot of knowledge.  And, from there, see if your interest and knowledge surpasses those of the people around you.  If it doesn’t yet, make it.

For instance, years ago as a workaday software developer, I learned a lot more about code metrics and static analysis than other folks.  It would be years before I figured out how to get people to pay me for that knowledge, but I developed it.

You have something like this.  Maybe you’ve learned some new, exotic flavor of markdown or you’re really good at designing APIs or something.  If you enjoy that and know more than others, look for opportunities in your work (and your free time, if you want) to go deeper on the subject and become an expert.

Then You Need to Start Learning Who Would Pay for It, And How Much

But don’t just go deep on this subject.  Doing that will just take you from commodity generalist to unemployable fetishist.  As you dive deep and/or learn adjacent subjects, you need to start understanding why these things matter to anyone.

For example, take my static analysis knowledge.  It started out as a way for me to win arguments about good and bad design pattern applications, but that was hardly a profitable niche.  Opinions about design patterns (and code metrics) are a dime a dozen.

But you know who loves code metrics?  Leadership.  Do you know who would pay a lot of money for custom code metrics to help them evaluate their source code?  Leadership.  (This is actually a gross oversimplification of the practice I’ve built, to the point of being a distortion, but I’m indulging in pseudo-fiction to make an easy to understand point)

Now, it might be that other software developers would pay for your knowledge.  A lot of folks make a nice living building info products aimed at fellow developers.  Or, leadership might value your knowledge.  Or completely non-technical people.  I can’t really say off the top.

Going from Laborer to Expert

But what I can tell you is that you already know things that people would pay for, if you can find them.  And when you cross reference the marketable things you know against the things that interest you, then you have the beginning of a lucrative practice.

And you also have an escape from the hamster wheel of never-ending generalists’ hamster wheel of tech stacks, since your knowledge will actually start to accumulate, rather than replace yesterday’s news.

But you don’t need to figure all that out today to make the future a place where people regard you and pay you like the knowledge worker that you rightfully are.  Instead, you have a much simpler task.  Start to think through the things that you know — not the labor that you can do — and think about who might pay for it, and why.  Figure out how to be a brain and not a pair of hands for rent.