Applied Consultant Taxonomy to Prevent Confusion

A few posts ago, I proposed a taxonomy for software consultants.  My reasoning for doing so was that I wanted to attempt a bit of clarification.  As software has taken over the world, “consultant” is no longer singlehandedly up to the challenge of describing everyone working in software not associated with any particular domain.

So I proposed the terms software pro, specialist and consultant as a means of bringing some clarity.  At the end of that post, I also alluded to a future post, in which I would talk about the problems that crop up when one of these personas is mistaken for another.  This is that future post.

Having been in and around the consulting world for a long time now and having served time in all three of these roles, I’ve seen firsthand how weird and sometimes damaging confusion of these roles can be.  There are too many permutations of mistake for me to want to list all of them in a post, so I’ll stick to the ones that are the most common and interesting, in my opinion.

The Aggrieved Grunt

For better or for worse, rightly or wrongly, software pros are regarded as the grunts of the non-salaried software development world.  Consultants and specialists are hired in non-delivery and possible-delivery roles, respectively, which means that they’re being hired for their expertise.  Software pros are hired into delivery roles, and while their expertise may interest their clients, it’s their labor that’s being purchased.

A non-expert labor purchase has two interesting characteristics for our purposes here.

1. It means that someone else, and not the software pro, is making the strategic decisions (i.e. “we’ve put together all the requirements and design specs and need you to code ‘em up”).
2. It puts the software pro firmly on the hook for execution.

Significantly, the software pro’s charter looks a lot like the line-level developer’s charter.  After all, architects and team leads make strategic decisions, and managers supervise delivery rather than owning it.  The grunt coders on the team, by contrast, faithfully execute the strategic visions of others.  So if we map the consultant taxonomy to familiar team roles, consultants are roughly like managers, specialists are roughly like architects, and software pros are basically developers.

Imagine then what happens when a person goes to a customer site or to an engagement thinking that he’s being hired as a consultant or specialist when the client views him as a software pro.  Also, remember that, in our world and without this taxonomy, all three of these roles are “consultant.”  He thinks that he’s being dispatched to provide strategic advice to management, but when he shows up, some project manager hands him an imaged laptop and a design document and tells him to get to work.

As you might expect, this is like someone taking a job with the title “manager” or “architect” and being asked to bang out code according to a spec.  It’s a significant enough perceived slight that it will likely set a pretty negative tone for the duration of the engagement, if the person in question doesn’t manage to beg off right away, which is somewhat likely.

This is probably the most acute bit of confusion, but in a way, it tends to be the least damaging in a “fail fast” kind of way.  With expectations misaligned like this, a clarifying conversation is likely to happen very quickly, leading to a higher chance of some form of remediation or another.

The Golden Hammer Consultant

Compared to the miscast grunt, this is a much subtler situation.  The golden hammer consultant arrangement generates nuance by virtue of the fact that both client and consultant expectations are actually aligned.  The client is looking for a consultant, and it hires a person that considers himself a consultant.

The trouble comes when, in spite of the client’s expectations and the consultant’s self-image, the consultant behaves as a specialist.

As you may have deduced by now, the golden hammer moniker arises from the ‘consultant’s’ behavior when supposedly solving general problems.  It just so happens that the solution to every problem is the same thing, and that thing also happens to be the consultant’s favored solution.

The instance of this that I’ve seen most commonly in the wild is Scrum for everything.  A consultant arrives on the scene, and all organizational woes, large and small, can be solved with a Scrum transformation.

Having trouble meeting deadlines?  Scrum makes things iterative.  Having trouble integrating separate development streams?  Scrum means continuous integration.  Having trouble with personnel and morale issues?  Scrum has retrospectives.  Having trouble with leftover food in the communal fridge going bad?  Eh… I’m sure that’s somewhere in the Scrum Guide near the back.  What?  You’re already doing a textbook implementation of Scrum and you’re having a problem?  You’re no true Scotsman.  Scrum harder.

I’m having a little fun with hyperbole here, so when you see it out in the wild, it’s not actually this obvious.  And the subtlety is what makes it so troubling – no one recommendation seems overly out of place, so it’s hard to see.

But, taken as a whole, what you have is someone hired and operating as a consultant, but in the tank as a specialist.  And this shortchanges all parties.

The Bewildered Advisor

The last observed case study that I’ll offer is the bewildered advisor.  This is not quite as subtle as the golden hammer consultant, but not as egregious as the aggrieved grunt.  The bewildered advisor is a software pro that finds herself thrown into a role where people expect strategic advice or specialist knowledge.

In terms of our taxonomy, this software pro is confused with either a specialist or a consultant, and that’s not what she signed up for.  At first blush, this seems like an easily solved problem – just say, “hey, above my paygrade,” right?  Well, not so fast.

I’m proposing a taxonomy to address this sort of thing, but, until everyone on Earth gets with the program, we live in a world where everyone is just called “consultant.”  So a software pro faced with an unwanted strategic question will necessarily think, “above my paygrade, but I need to say something.  I’m a consultant, after all, and I wouldn’t want the client or my employer to think I dropped the ball.”

And that applies only to the modest software pro.  Another distinct possibility is that the requests for advice go to the person’s head, and they assume that being asked makes them qualified to answer.  This adds even another wrinkle to the problem, as they may begin to hold forth as if they had the experience and depth of knowledge of a specialist or the strategic vision of a consultant when they may well not.

Driving at Clarity

I could list more possible scenarios, but I suspect you get the idea, and you can, no doubt, dream up other mismatches.  And I believe I’ve made clear both the conundrum and the types of damage that can result.

What’s the solution?  Well, let’s not overcomplicate things.  It’s simple and direct.  Going into any arrangement where you provide some kind of software service to another organization or party, clarify expectations.  Are you being hired to provide labor, to provide specialized knowledge, or to provide strategic guidance?

The taxonomy can help with this.  Introduce the terms, and use the inevitable request for clarification to, well, clarify.  But you don’t need the terms or the taxonomy.  You just need ot make sure you agree on the definition of success before you start doing the work.