DaedTech

Stories about Software

By

Software Consulting: What This Really Means and How to Start

On this blog, I’ve talked at length about both software development and consulting.  In fact, I have an entire posting tag devoted to transitioning from being a developer to being a consultant.  This includes a take on why everyone should want to.  So I’ve got the subject of software consulting surrounded.  But now, I’d like to get into the nitty-gritty.

I’ll link off to plenty of opinions for further reading as I go, but this is all about defining what software consulting is, how to start doing it, and how to make a living.

What is Software Consulting? For That Matter, What is Consulting?

Let’s start as simply as possible.  In order to know what software consulting is, we need to define consulting itself.  The business dictionary has a pretty serviceable definition (emphasis mine):

The providing of expert knowledge to a third party for a fee.  Consulting is most often used when a company needs an outside, expert opinion regarding a business decision.

Simple enough, right?  As a consultant, businesses hire you, an outsider, to furnish an opinion.  You’re selling your own hard-won knowledge.  And what you’re not selling is your labor.

So software consulting is just doing this same thing, but with a narrow focus on software.  Right?  Still pretty simple?  Case closed?

Well, the case should close there, but, sadly, it doesn’t.

Why Most Definitions of Software Consulting Aren’t Helpful

We in the software industry have managed to take a simple definition and… complicate it… to the point where it means something totally different.  Think of the way the definition of “literally” also includes “not literally.”

Go do a google search on software consultant, and look at the definitions you find.  Seriously, go look.  You’ll find various definitions, but they generally add up to the same idea.

Software consultants are software developers that work for companies that sell software development labor.

How did this come to pass?  Why does the definition of “software consultant” include “software developer that does not consult for a living?”  Why do we literally need a whole taxonomy to determine if a software consultant is a software developer, or literally a lost soul in some professional purgatory?

Well, the backstory there is complicated.  But the short version is that it comes from a time before today’s ubiquitous computer programmer.  When few people “did IT” for a living, the folks engaging them valued both their expertise/advice and their labor.  But these days, it’s mostly just labor.

I’ve got an idea for an app!  Now I just need you grunts to build it.

Way back when, companies engaged tech vendors for expertise and labor and called them consultants.  Today, they still call them consultants, but just engage them for labor.

Read More

By

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?

Read More

By

You Should Change the Reason People Pay You

Quick — what’s the reason people pay you?  Don’t ponder.  Just freeze the first thing that comes into your mind.

It’s probably something like this, especially if you’re a salaried programmer.

I have a valuable skill that’s in high demand: programming.

On a surface level, I can’t really argue with that.  Recruiters pester you constantly, and companies regale you with the superficial perks that can be yours if you just jump ship and come work for them.

But your skill and the demand for it aren’t the whole story.  In fact, I’d argue, they’re not even precisely the right story.

Why Do People Give Programmers Money?

Let’s tweak your prognosis slightly, without changing the economics around it.  You think of yourself as a knowledge worker that has a skill in high demand.  But your employer views you as a commodity in short supply.

What’s the difference?  Isn’t this semantic quibbling?

Not at all.  Inadequate supply can create excessive demand (or vice versa).  But they are not the same thing.  To understand what I mean, think of runs on grocery stores for canned goods before major storms come through.  Cans of baked beans are budget, commodity goods that nobody would generally call “valuable.”

But that all changes when a hurricane appears on the horizon and people hoard canned goods for the aftermath.  Gougers can charge way more for canned baked beans because it’s a commodity in short supply.

As a salaried programmer, you’re a can of baked beans.  Don’t confuse short supply with intrinsic value.  The world is starving for efficiency, and it anticipates even more starving later.  Employing you is a hedge.

Read More

By

How to Become a Management Consultant

Last week, fate (via Hacker News) sent a lot of people to this post, about becoming a software consultant.  This actually resulted in a lot of new readers and followers.  So, first of all, hi to all of the new readers and followers.  But secondly, I’m about due for another consulting post.  So let’s talk today about how to become a management consultant.

This is going to be a guide to charting a course for yourself from working as an individual contributor to a management consultant.  And it doesn’t involve dues-paying or working your way through any degrees or even any other jobs.  It’s a lot more direct than that.

First of All, What Is Management Consulting?  It’s Not as Pretentious as it Sounds

First things first, let’s get to definitions.  I’ve often referred to myself as a management consultant.  (If you want a more detailed history of my consulting, you can find that here.)  Sometimes I call myself a strategy consultant or perhaps an executive consultant.  In a sense, this is all kinda the same thing.

So let’s define that thing.  What is a management consultant?

You could probably find all sorts of definitions out there of varying complexity.  Let’s go with a simple one, though.  First of all, as I’ve explained before consulting is when people pay for your expertise and opinions.  (Not your labor.)  Management consulting is thus a narrower variant of general consulting, with the following two caveats.

  1. You are specifically offering advice to organizational leadership (i.e. “management”).
  2. The advice you offer is related to leadership’s main charter: making organizational decisions and running the business.

That’s really it.  You give advice to organizational management about how best to execute their leadership duties and oversee their organizations.  Naturally, there are a lot of different kinds of advice that you could give, but I’ll get to that a little later.

Should You Become a Management Consultant?

If you’re reading my blog, you’re probably a software developer or at least software-developer-adjacent.  So given the post title and introductory section, you might be looking behind you and wondering if I’m not talking to someone else.  You might just want to write code, either for a company or as a freelancer.

Is this advice really for you?

Yes, it is.  I’ve previously advocated that every software developer become a consultant.  So it’s not much of a reach that I think, if you’re going to become a consultant, you might as well become a management consultant.  Developer Hegemony, aside from being a book, is the crazy idea that software developers should be in charge of software development.  And if we’re going to be in charge of our own industry, it stands to reason that we should know how to run it well enough to offer advice about the same.

So yes, you should become a management consultant.  It’s an excellent way to establish a practice, credibility, industry contacts, and authority.  And the pay isn’t bad, either.

You don’t have to live out of hotels or wear slacks everywhere, or adopt an insufferable vocabulary, either.  Heck, you might not even need to leave fulltime employment, if you get creative.  You just need to establish yourself as an expert in some facet of leadership in the software world.

Read More

By

Being Good at Your Job is Overrated

Let me be clear about something.  This title isn’t clickbait.  I mean it.  But I mean it literally.  Being good at your job is overrated.  We value it too highly.

If you’re a long-time follower of this blog, you might think this is a curious sentiment against a backdrop of advocating for practices like test driven development.  And if you’ve wandered here from somewhere else, you might think this vacuously contrarian.

In either case, relax.

Being good at your job has value.  It’s certainly better than being terrible at it.  But it’s not nearly as important as we think it is, in the grand scheme of things.  The world weaponizes our love of mastery against us at times, causing us to lose sight of other considerations.

I’ll back this claim up with more explicit reasoning a little later.  But first, because I’m back to amusing myself with the blog, indulge me.  I’m going to tell some stories.

Read More