The Hardest Part of Consulting
The hardest part of consulting is surprisingly not working with old tech. Nor is it working with difficult personalities or being an “other” in another organization either. While these can certainly be challenging, they aren’t the toughest.
Instead, I’ve found the hardest part of consulting is seeing the root causes of problems and not being allowed to fix them. The reasons for this vary but usually revolve around an expectation that you should “stay in your lane” so to speak.
Especially if the reason you were brought in was not explicitly to fix the root problem.
For example, a company brings you in to fix Application X. You discover that X is a minor symptom of a much bigger Problem Y. However Problem Y will not be solved for reasons such as political, financial, or otherwise.
Consultant or Software Pro?
Erik Dietrich, who runs the fantastic Daedtech blog, has a great post about the Taxonomy of Software Consultants. In Erik’s parlance, much of what is referred to as “consulting” these days would fall in the Software Pro bucket.
I’ve found this to be true in my experience working for a great consulting firm here in the Twin Cities. The local market just seems to want Software Pros more than it wants Consultants. This seems to hold even when clients pay for Consultant level personnel and then have them do Software Pro level tasks.
Marketing is no doubt a big factor here. Acme Software Consulting sounds better than Acme Software Contracting.
So the natural tendency will be for contracting shops to pitch themselves as consulting shops in order to charge higher rates. While time and reputation tend to sort these things out eventually, it still muddies the waters for clients seeking help with their IT departments and projects.
Suboptimal Engagements
This nebulous environment can lead clients towards suboptimal engagements. For example, a client who has serious problems with their development process hires a Consultant. The Consultant then identifies several areas to improve the dev team’s velocity, yet the client resists any such changes.
In reality, the client only wanted a Software Pro to keep an old hairball of an application running, because their own dev team could no longer handle it. This is unfortunately all too common. Solving the root cause of the hairball would lead to a better outcome, yet this is not what the client has contracted you for.
One of the big advantages of being a consultant is looking at a client’s development team and processes with fresh eyes. You’re not tied to past decisions that may have fared poorly.
It’s this clarity and independence that makes it much easier to see what can be improved. Convincing the client’s management to do so however is another matter.
The Minefield
This leads into one of the minefields of consulting. That is, navigating the politics of host organizations and coaxing them to solve the root causes of their issues.
This can be especially tricky when these issues may be caused by the client’s management or technical leadership. How do you gracefully tell a client’s management that their FTE Architect has built their app into a Rube Goldberg contraption? Particularly if that Architect has been in the role for some time and is well regarded in the organization. Not an easy sell.
Likewise, imagine the client’s management is a mess and is the core reason their dev team can’t deliver. If you’ve been engaged by said management, it’s not likely to go well if you inform them that their approach needs an overhaul. Especially if they’ve brought you in to fix what they perceived to be a software problem.
These are all emblematic of the hardest part of consulting. In short, identifying the root causes of a dev team’s problems and not being empowered to fix them. Instead, you’re often expected to stay in your lane and fix only what the client wants, though it may be of far lesser impact.
Summary
The hardest part of consulting I’ve found is not being empowered to solve root cause problems. Sometimes clients just want specific tasks handled and are not interested in more comprehensive solutions.
One cause of this is the muddied waters of what a software consultant is these days. Software Pros and Consultants have become largely synonymous. So clients often expect their consultant to stick to Software Pro level tasks.
This often leads to suboptimal engagements. Largely due to far narrower scopes of work than would be ideal.
Trying to bridge the gap between what the client wants fixed and what really needs to be fixed can be a minefield. Navigating the politics of a client organization is difficult even in the best of circumstances.