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.