The Consultants Code

February 1st, 2018

I wish we could have built it right the first time but we were learning along the way.

Ugh, we got handed this mess and now we have to figure out what to do with it.

What do you think we should do?

Sound familiar? If any of these statements resonates with you then you’ve most likely been in the shoes of the person making the statement or as a consultant engaged with a client in a similar predicament. The phrase “Software Consulting” generally evokes feelings of praise or disdain, or perhaps both depending on the circumstances. As consultants, we are often positioned as experts and typically engaged during times of crisis or uncertainty; so it should come as no surprise that our ability to deliver in the midst of that environment is the primary measure of our effectiveness.

Expectations about what we are hired to deliver generally set the scale by which we are judged; frequently that involves analysis, reporting, recommendations but also training, mentoring, and code. The world is a big enough place that it’s plausible to think of a scenario where the opening statements above were made by someone dealing with the aftermath of a poor experience with a previous software consultancy, typically measured by the state or quality of “the code”.

While it would be interesting to attempt an objective look at what typifies “quality” as it relates to “code”, I think there is a more interesting vector to approach the quality valuation that also pertains to “code” of a different kind; call it the code of conduct, or the way we interact with our clients as consultants, or perhaps even our ability to relate and help them rise out of the midst of chaos and uncertainty—this type of consultant’s code is less frequently explored, which is a shame, because I firmly believe it has a more direct impact on the physical code we write than our technical expertise.

Hostile Takeover

Consultants in any industry are often vilified from the start of an engagement due to a perceived “us vs them” mentality. Depending on the how the engagement was initiated, trust was likely extended from key decision makers but generally does not extend from the rank and file employees of the company. This puts an immediate burden of responsibility on the consultant to become adept at earning that trust inclusively and at discerning barriers which would prevent that from happening.

The key to building this trust starts with establishing relationships with everyone on the team. It might be easy to think of ourselves as only accountable to the primary stakeholders, but unless we earn the trust of our peers and treat them as equals, it will be challenging to avoid the perception of a hostile takeover. In essence we should think of ourselves as partners, invested in the success of the company and each member of the team. Finding opportunities to mentor team members and attribute wins to others is a great way foster a positive consulting environment.

Cooperation & Commiseration

At some point any consulting engagement will involve hearing about the technical failures, company problems, personnel issues, and every other negative thing under the sun; people like to complain. Good consultants know how to view these conversations as opportunities to build trust without becoming embroiled in corporate politics. It is a balancing act to be able to participate in just enough commiseration to demonstrate understanding without fostering a negative cycle. I believe a critical component to developing this skill is the ability to hone one’s capacity for active listening.

There is a fine line between commiserating and ruminating, and good consultants know how to empathize and then steer the conversation towards solutions instead of ruminating on past failures.

Technical Overdrive

Depending on the nature of the team and the consulting engagement, it may prove more effective to lead by example and jump into what I like to call “technical overdrive”. I’ve seen many teams become derailed in endless technical round-table discussions and talk themselves into a corner before ever trying to code up a prototype or draft solution. In these scenarios I have found it best to move forward with quick prototypes of solutions proposed by the team, enabling them to have more concrete discussion points and base decisions on actual implementations. Working code and a good demo can unblock many teams.

Like every piece of advice, when to jump into technical overdrive is highly context-sensitive; sometimes it is more appropriate to employ the opposite strategy and slow things down. Some teams have a bad habit of shipping their prototypes to production, and it is in this scenario where good consultants will try and introduce better habits around technical design, architecture discussions and how to effectively prototype. In some ways the slow-things-down scenario also involves technical overdrive, as it might mean taking the lead on demonstrating what these good habits look like for the team.

Closing Thoughts & Recommended Reading

As a consultant, building trust should be our number one goal, but we have to remember that it takes time and is a skill that needs to be cultivated over the course of many engagements. If you are interested in spending time honing your skills and improving your “consultant’s code” I would recommend investing in the following resources:

Also, if you’re looking for a great opportunity to develop your consulting skills, they are hiring at Test Double, you should apply. :)