Most Software Consultants Aren't Consulting

"Consulting" in software development is often aspirational, akin to software engineering being a somewhat watered-down form of engineering, as compared to the classical disciplines it borrows its name from. It's just as easy to conflate craftsmanship with engineering, as it is to conflate contracting with consulting.

Most people in this business are software developers turned consultants—they are trained as builders. It's hard for them to shake off the mindset and behavior of skilled laborers with better day rates, whereas a traditional consultant's job is to diagnose, to advise, to challenge, and to be a strategic partner.

If all you do is solve problems the client tells you about, you're not a consultant. Now there is nothing wrong with working on the conveyor belt of Jira tickets, and this is a part of most projects, but there is a whole world of opportunity out there to have a much broader impact and more rewarding experience-if we just welcome a reframe.

It's not about what you can deliver, it's about what creates value for the client

You're not just paid to deliver code. You're paid to deliver some change, some outcome that the client values. Clients for the most part don't care about how clever you are, or how fancy your solution is. They care about outcomes.

Many software consultants operate with an upside-down perspective. They attribute value to abstract artifacts of their world, things like the tools they use, how many releases are done or even obtuse concepts like "story points delivered". These are hopefully tied to the outcomes that the client actually cares about, but the disconnect is a distraction and can lead to "busyness" with little value-add.

As you internalize your client's perspective you'll (both!) be much more poised for success. You'll also identify many pitfalls in how things are usually done in the world of software development consulting.

I'll attempt to identify some of them, below.

Common Pitfalls of Software Consulting

1. Measuring success in terms of code, instead of outcomes

It's common to report on such things as test coverage, number and severity of bugs / defects, build times, or features delivered. While these may have their place, they are examples of measuring output, not outcomes.

Outcomes would be things such as trends on user churn, feature adoption, time from user issue raised to closed, time taken to perform certain task, marketplace ratings, process streamlining (reducing number of tools needed), etc.

2. Thinking in tools, not levers

Focussing on tools and tech stacks at the expense of deeply understanding the problem at hand, and the broader options available to address it.

3. Being reactive instead of proactive

Cue the conveyor belt analogy again. Instead, think strategically and provide advice! Shape the direction of work.

4. Lack of business fluency

Your speak in tech terms, not business value. Adopt the language of your client.

5. Undervaluing persuasion

It's your responsibility to be a figure of authority for your client. Don't mistake access for influence.

6. Avoiding conflict to "be easy to work with"

Think critically and challenge bad ideas. Otherwise, the client will always be in the driver seat.

Weren't your hired for your expertise?

7. Solving the wrong problem really well

We've all been there, haven't we?

8. Confusing tech debt with value debt

Tech debt is only worth addressing in the service of measurable business outcomes.

9. Busyness over leverage

Equating time spent coding with value delivered. They are often completely disconnected.

10. Taking pride in complexity

In other words, over engineering. It's usually a symptom that somewhere along the way, we lost focus on the outcomes.

11. Getting sucked into the system

Or colloquially "being absorbed by the borg". Endless meetings to attend, reports to read, dashboards to produce.

Take a step back and question the structure.

12. Over-automation

Throwing code at everything. Some times the best solution is not a technical one.

Effective consultancy requires interpersonal traits and interests that are often missing or repressed in those of us who feel most confortable coding all day. It is however something completely worthwhile investing in, with benefits that are long lasting and transferable to other areas of our lives.

It's mostly an exercise in constant re-framing, and having the discipline to take a step back from the nitty gritty to get a proper feeling for the impact of what we're working, where value is actually being added, and the interests of those involved in it. So get to it!