A Taxonomy of Software Consultants
The conversation that follows this paragraph is a dramatization. But it’s a composite of actual conversations that I’ve held, distilled and focused. And I think it will illustrate why I believe we need a taxonomy of software consultants.
“What do you do?”
“Oh, I’m a software consultant.”
“Oh, nice. So, what, you like, go out to client sites and help them with their projects?”
“No, I work for a software consulting firm and I just go there. My company writes apps for other companies, and I’m on a team working on something for one of those companies.”
“Ah, okay. Do you interact with your client over the phone or via chat or something?”
“No, that’s mainly the project manager — I just code up requirements.”
“Oh, gotcha. So no one really consults with you, per se.”
“Yeah, huh, I guess not. I guess I’m more like a contractor or something.”
The surface problem here is that the definition of consultant has been somewhat watered down. But I’d say the deeper-seated problem is one rooted in history.
In a world (of, say, 30 years ago) where software was mainly a maintenance concern for line of business automation and hardware-based products, the people that wrote code were employed by the companies that consumed the code they wrote. Someone without domain knowledge that went around writing software would rightly have been considered a consultant, since specialized knowledge of software was uncommon. But as the balance of the world shifted to software being ubiquitous, someone unmoored from a particular domain, writing code for a living, is no longer highly specialized nor is that person likely to be consulted for their unique expertise.
As the world evolved, however, the terminology did not. A software consultant continues to be defined as “anyone who writes software for a company other than the one direct depositing pay into their bank accounts.” This can be the ‘consultant’ described above, an agency staff augmentation, a CRM specialist installing a CRM installation, or a person advising the dev manager on a migration strategy. To gain some clarity, I propose some clarity around terms.
I thought about actually just calling this one “software developer,” because that really kind of reflects modern reality and will only grow more and more true. I think that the days of software developers working en masse for major, large corporations are numbered, frankly. Software developers working for furniture manufacturers and pharmaceutical companies will do so not as W2 employees but as free agents or employees of software development firms (what I tend to think of as “app dev consultancies”).
But let’s call these folks “Software Pros.” They’re not consultants at all. They’re just software developers that ply their wares serially at different organizations on a project by project basis. This describes the conversation participant in my hypothetical composite — a person working for a firm that sells app dev to companies. Of course, this label can also apply to an agency staff augmentation — the ‘contractor’ at your company that has been there for 2 years and acts as part of the team, but gets paid by Robert Half or some similar firm instead of your employer. Likewise, that is not a consultant but a software pro.
Next up is the specialist. A specialist is a kind of consultant, but more around for tactical and situational expertise than for general advice. For example, I mentioned a CRM specialist earlier. A CRM specialist would come onsite with a client to help the client with all things CRM. It could be an actual installation or it could be advice on whether or not to change CRM technology. This is not to say that the specialist’s advice on other matters might not be relevant or interesting, but the specialist is there for narrow expertise.
Keep in mind that “C#” or “Ruby” isn’t really a specialty in this day and age. The skill in question has to be in demand and fairly niche. I can’t offer exact criteria, but for the purpose of this taxonomy, consider that “programming” or a programming language wouldn’t qualify (unless, perhaps, you had a Jon Skeet-like level of knowledge). Knowledge about a specific product, framework, pattern, etc would.
Last up, let’s take back the term consultant. Or, let’s at least make it a little narrower in the field of software.
The software pro is hired to perform labor without really examining the bigger picture. The specialist is hired to furnish expertise and use discretion as to whether or not to perform labor. In this sense, it’s sort of a hybrid labor-adviser position with an option for either or both. The consultant is strictly an adviser.
An important and subtle distinction thus arises between consultants and specialists in terms of their charters. Specialists have a natural interest in evangelizing their specialty. Our CRM specialist won’t necessarily advise anyone and everyone to adopt CRM, but they’ll certainly have a tendency to view CRM as a hammer and a lot of problems as nails. It’s in their own interest and the interest of their practice, and it stands to reason that they’d believe in the thing they’d opted to specialize in.
Consultants, on the other hand, will have allegiance focused more purely on their clients’ outcomes. Like specialists, they’re interested in advancing their own practices — this isn’t purely a matter of altruism. But, unlike specialists, they are there hired in a more general problem-solving capacity. They advance their practice by being known for listening to their clients, tailoring solutions to them specifically, and notching glowing referrals.
The Importance of a Taxonomy
I’m a good number of words in and I’m somewhat tired, so I’ll conclude here and come back later with a follow up post. I certainly like to form clarity around terms and with my thoughts in general to further understanding. But there’s more at stake here, I feel.
Having done an awful lot of consulting over the last 5 years (as well as some specializing and software pro-ing), I’ve witnessed what happens when some folks are expecting one of these roles while others are expecting another. Those situations tend to range from causing awkwardness and angst to creating outright disasters. As a quick example, imagine that you think you’re being hired as a consultant, and you walk in on day one of the ‘engagement’ to a line manager handing you some orientation materials and telling you to get to work. You’d probably be unhappy to consider yourself a consultant and be mistaken for a software pro.
Things have changed a lot since the dawn of software, and a lot of the terms we’ve been carrying around have a lot of cruft all over them. I’d like to see if we can kick that off and start fresh.
Editorial note: in the years between writing this post and now, I realized that I was omitting a fourth type of “consultant” from the taxonomy. I wrote in depth about that here.
A search engine expert might be a good example for either a Specialist or a Consultant, depending on what the customer needed. A lot of people go into a search design with approaches that are known to be bad. A substantial chunk of the traffic on the solr-user mailing list is asking people what their real problem is, instead of telling them how to implement the poor solution they chose.
Definitely a good example. I can relate from the other side here, too, because SEO is something that matters to me but I’m no expert at it, by a long shot.
I was thinking more about configuring site search or enterprise search. Things like when to match plurals, what synonyms to use, handling different languages, and so on. There are always weird linguistic things and surprising matching behavior. Or even more surprising user behavior.
SEO can get complicated, but as long as you have pages that are readable by people and useful to people, everything else is just icing. The WWW search engines are trying to emulate human judgements of relevance. Don’t overfit their current algorithms, just keep it real for people.
It seems like its a particularly useful taxonomy for the ambitious: I suspect (not personal experience) that its hard to command a higher rate than $100/hr or so as a software pro, whereas as a true consultant the upper limit is much higher. Though, I wonder if the waters are muddied from the customer’s standpoint because a good “app dev consultancy” can provide strategic advise in a package deal with the development expertise to implement that advise, even though the majority of people working at the consultancy will be “software pros”
In terms of comp, yes, I’d argue that a true consultant has almost no cap on hourly rate. A software pro definitely does, somewhere or another. In my experience, software pro’s time can go for $150/hour to clients, but it’s rare for that person to be getting all of that. It’s usually a firm commanding that rate. And, yes, pretty much every firm that supplies app dev will also try to sneak a project manager, architect, or ‘expert’ in on the project, which pulls up the average rate via what is called “blended rate.” The reasoning here is that these… Read more »
Every contractor/consultant has his day when he realizes he’s being pimped. The client pays $100/hour, and the middle man takes half. It’s not long before we start asking ourselves how we can cut out the middle man. Then we realize that it’s not as easy as we feel it should be. The middle man is either a true value add, or a bottom feeder, depending on your perspective.
One thing I’m hoping to do in the coming years is to make doing that easier for individuals that want to. I’ve written about this in the past and it’s a subject that interests me greatly, but my tl;dr take is that the middle man employer certainly adds value (in the form of stability and the like) but not commensurate with people’s perceptions. I say this because only a fraction goes to ‘stability’ and the employer incurs a lot of operating expenses that don’t really, directly benefit the worker very much (shareholder payouts, facilities costs, overhead salaries, etc). But, that’s… Read more »
I actually just pulled this off myself (though not in software development). i was on a project and the client liked my work in particular and decided she wanted to put more money on the contract with my company. My company didn’t have anyone else that could fill my spot, so I used that as an opportunity to go independent and capture 90% of the billable rate. It’s basically a supply and demand play, where you have to back make the supply and demand of 1 point to you. In consulting land, the quickest way to do this is to… Read more »
Definitely solid advice (though it could skirt the edges of non-competes that some folks might have in place)
[…] how to become a consultant. Freelance software development is not, in my opinion, consulting. I refer to people who do that as software pros. Firms pay consultants for their opinions and they pay software pros for their labor. I draw […]
[…] You need to differentiate yourself. Figure out how to offer a productized service (e.g. the aforementioned “I’ll migrate you to git”). Become enough of an expert to consult. (And I mean actually consult — not just bang out code for someone else and call yourself a consultant.) […]
[…] Since most of my readers are software developers, I’ll talk about the different flavors of consulting in that field. I’ll even discuss ones that fall under this heading only because the software world has a bemusingly wide array of people that it calls consultant. […]
[…] 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 […]