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.

A Better Definition of Software Consultant

So let’s improve on the watered-down, stock definition.  Let’s define software consultant in a meaningful way, so that you become an actual expert, rather than a laborer.

This isn’t actually that hard to do.  It just involves taking the actual definition of consulting and narrowing the focus to the realm of software.  So, what is software consulting?

The providing of expert knowledge in the software space to a third party for a fee.  Software consulting is most often used when a company needs an outside, expert opinion regarding a business decision.

A software consultant is then simply someone who offers software consulting services, as defined above.

To drive home the point, consider the following list of things that are not software consulting.  And I do this not to be snarky or flippant — just to be crystal clear.

  • Working for a ‘software consulting’ company is not software consulting.
  • Writing code for pay is not software consulting.
  • Writing code for pay while sometimes offering opinions is not software consulting.
  • Acting as a project manager or tech lead for a team building software for a client is not software consulting.

I could go on, but hopefully you get the point.  You’re only offering consulting if people are paying you exclusively for your expertise on a topic.  If they pay you for your expertise and then also pay you for service delivery, you are, in sequence, starting as a consultant and then becoming a service provider.  There’s no law saying that you can’t offer multiple things or switch modes.  But you’re only consulting when people pay you for knowledge/opinions/expertise.

How to Get Started as a Software Consultant

At this point in the explanation, a lot of folks tend to suffer and then shake off a bit of dizzying cognitive dissonance.

I thought writing code for a company other than my own company made me a consultant…  but, I guess not.

And then from there, their thinking goes one of two ways:

  1. {shrug} “I guess I’m not a consultant then.  Oh well.”
  2. “Crap… so how do I become an actual consultant?”

For the rest of this post I’m going to address folks in camp number (2).  I generally wish folks in (1) would make their way to (2), but it’s not really in my nature to belabor arguments about people’s career choices.

For folks in camp (2), the path can seem daunting.  If you’ve spent your career earning money in exchange for labor, the idea of earning money in exchange for your opinion probably seems equal parts alluring, improbable, and alien.  But it’s really not farfetched.

Here’s a game plan for making the shift.

1. Shift Your Mindset from Labor to Expertise

You’re going to be tempted to skip this first one, since it probably sounds a little woo-woo.  Don’t.  It’s important.

You’ve spent a career earning what is probably a very nice living through labor that you perform.  People give you specs or user stories and you turn them into code.  You do this in exchange for either a salary or an hourly rate as a freelancer.  In both cases, this makes you a laborer — a pair of hands.  Companies pay not for what you know, but what you can do.

And, as software developers, we’ve embraced the labor concept.  We toss around terms like “craft” to indicate that we care and “maker” to indicate that we really, actually build things.  But this actually functions as sort of a career glass ceiling.  We’ve taken these metaphors too far.

Snap out of it.

Don't sacrifice your positioning strategy to code-jousting sites, as illustrated by this joust-ready knight.

People don’t pay lawyers because those lawyers are really awesome at typing up briefs.  And people don’t pay general practitioners because they’re really good at stuffing pills down your throat.  Instead, we pay lawyers to know what briefs to type, and we pay doctors to know what’s wrong with you and what pills you need.

So take a look at your career and skill set and start to ask what knowledge you have that people would pay for.  Think constantly about who might pay for your opinions and expertise and why.  Brainstorm.  You won’t think of it immediately, but ideas will come.  And however quickly or slowly they come, the important thing is that you’re starting to value yourself not for what you can do, but for what you know.

Stop being a pair of hands and start being a brain.

2. Look for Work with an Agency

Next up, let’s switch from the fairly abstract to the extremely concrete.  Start to look for work at an agency.

Ideally, you’d look for work at an actual consulting firm.  Do this, and they’ll teach you the ropes and give you valuable experience.  But it’s tough to go directly from writing software to consulting without an interim stop.

So I’d suggest looking for work with an agency that sells app dev.  These are easy to identify because they usually call themselves consulting firms.

The idea here is to get used to the paradigm of having a rotating series of clients/customers.  You’ll also pick up knowledge about the mechanics that will serve well for actual consulting, such as how billing works, the business model, etc.

Think of this as an excellent stepping stone between working as a cost center or for a product company and being an actual consultant.

3. Practice Your Skills and Look for Actual Consulting Opportunities

As you look for work with an agency and then find it, take every opportunity to practice consulting and honing consulting skills.  I say this because, while I’d argue that you can’t reasonably call yourself a professional software consultant unless people are paying for your expertise, you can approximate the experience.

You’ve been shifting your mindset to expertise and brainstorming what knowledge you have that people would pay for, right?  Well, put that to use.  Keep your eyes open for people within your organization or at your company’s clients who would be interested in what you know.  Then, offer to help them.  This is a nice, low-stakes way to practice consulting.

If you struggle to find opportunities, volunteer!  For years, I used to volunteer an afternoon each month to a startup incubator in Chicago, where I’d serve as a free “rent-a-CTO” for startups looking to get off the ground.  Talk about valuable consulting experience.  I’d go down there every month and give advice to any and all technical questions that people threw at me.

4. Lay the Groundwork for Your Own Practice

Here’s another angle that you can pursue in parallel with the last couple.  Start laying the groundwork for your own consulting practice.

I say this realizing that you may want to stay employed indefinitely.  Maybe your ultimate goal is to go work for PWC or or Deloitte or whatever, becoming a real consultant at a big-boy consulting firm.  That’s fine.  Lay the groundwork anyway.  It’s good experience.

Yes, I really do think that everyone who is even remotely thinking about it should incorporate.

Start an LLC.  Setup accounting software.  Draft stock templates for things like proposals and contracts.  This is an amazing education in how to run a business or practice end to end.  It teaches you about parts of a business that you may well never have experienced: operations, finance, etc.

Whatever your ambitions, you make a much more credible consultant when you have end to end knowledge of how a business works.

5. Develop an Offering

By this point, you have a few different things.

  1. Experience working for an agency and understanding how billing models and such work.
  2. Practice with consulting skills and offering expertise.
  3. A business of your own and experience setting it up and operating it.

You’re in pretty good shape!  But what you don’t have, at this point, is a specific offering as a software consultant.

Salaried employment teaches you some things that don’t serve you well running your own business.  One such thing is being a generalist.  Being a generalist makes for a good long-term laboring employee, but not so much for a consultant, due to the lack of a specific value proposition.

So watch out for the trap of going to market as a consultant by saying, “I can offer advice on all things software!”

You need to develop a much more specific niche.  Become an expert in something specific that matters to people.  But, beyond that, you need to come up with what, exactly, you’ll offer the market.

Of course, you can bill yourself as a generalist, or even a relatively niche consultant with an hourly rate.  But I’d suggest going deeper than that to get traction.  Develop an offering beyond time for money.  Offer a roadmap or a specific consultation or something.

6. Start Moonlighting, but Only as a Consultant

Once you’ve got the skills, the infrastructure, and the offering, you’re ready to take what you have to market.  Start making some money as a brain and not hands!

But I’d do this in low risk fashion at first.

The beauty of consulting — selling knowledge and expertise — is that you can offer this service with a very small scope.  As a software developer, it’s hardly worth getting out of bed for a custom project unless it hits the 5 figure range.  But as a consultant, you can bill 4-5 figures for a single day of work, assuming that you have valuable enough expertise.

This means that you can (and should) moonlight.

Even as you keep your day job, start looking for targeted consulting opportunities.  This will, of course, make you money, which is always great.  But it will also let you do a kind of end-to-end integration test of your consulting business model.  Moonlight until it’s your day job holding you back.

7. Decide If and When to Go Off on You Own

The last thing that I’ll offer in terms of steps for getting started is both philosophical and important.  And, I offer this last by no coincidence whatsoever.  Don’t decide about this until you’ve executed everything up to this point.

Once you’ve developed the skills, infrastructure, and experience as a consultant, decide whether you want to run your own show, or whether you’d like to take those skills and experience (probably not the infrastructure) to an employer instead.  I don’t think you can make a truly informed decision about whether or not to do this until this point in the process.

There’s really no downside here.  Everything I’ve laid out will make you a better independent business owner as well as a better employee.  And whether you go independent or not, you’ll find yourself consulting now in everything that you do.

Yes, I Think Every Software Developer Should Do This

Early on in this post, I linked to a previous post of mine about why I think that every software developer should become a consultant.  And I want to close by reemphasizing that point.

I love building and making things.  Seriously.  Not only do I have almost 2 decades of software development experience, but I also love, in my spare time, to cook and take on home improvement projects.  The act of creating something and the labor involve generate deep satisfaction.

But the flip side of this satisfaction is that we software developers, by positioning ourselves as laborers and not experts, have ceded authority to just about everyone else in terms of decision making about software.  Software developers are, somehow, the least important people in the software industry.

There are a lot of reasons for this, I’d say.  But first and foremost among them is that we sell our labor and punt on our own expertise.  We’re pairs of hands and not brains.  Imagine what would happen if we reversed that trend.  Imagine what would happen if we commanded respect for our expertise and advice, instead of passively aggressively venting to one another through XKCD and Dlibert comics.  We’d live in a world that placed a premium on knowledge of software when making decisions about software.

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.