Back

TechnologyMay 23, 2016

Speaking Consultant for the Technically Inclined

Christopher Blewett, and Patricia Anderson

One of the biggest differences between being a developer in the industry as opposed to consulting is the amount of exposure we have to non-technical client management. In the consulting world, our job demands that we are both technically adept and capable of representing our firm and ourselves well. The technical side of consulting is easy to come by, as school and industry experience can usually provide the requisite skillset. However, the “soft skills” portion is often acquired in the field. Please, let us shorten your “field training” by giving you a Rosetta Stone for technical consulting.

opportunities for linguistic optimization

What you want to say…

What you could say instead…

“Yesterday I spent all day fixing a merge that was a disaster.”

or…

“I need to go back and completely redo this code because it is awful.”

“Yesterday we worked through and resolved some challenges with the upcoming feature release merge.”

“I have identified some areas of improvement that I would like to revisit. Doing so will make the code base more robust/maintainable.”

We want to be honest and avoid “consultant-speak,” but words like “disaster,” “awful,” and “horribly wrong” can scare a client—and are probably not truly accurate. Everyone hates the code they wrote a year ago.

“There is no way we can do this many stories in a two week sprint.”

“That sounds interesting, let me speak to some team members and get back to you on that.”

It may truly be impossible, or there may be more factors that we as developers might not fully understand. Fortunately, we work with a bunch of smart individuals and between all of us we can solve most anything.

“You are wrong. Micro-services are obviously the way to go and any other way is idiotic.”

“Hmm, can you explain why you think that?… Very interesting… let’s discuss this further.”

Often, if we can get more context about why someone holds an opinion, it becomes easier to find a mutually agreeable solution.

“I have no idea what I am doing. This is the first time I have ever looked at Java.”

“I’m determining the best approach to the problem.”

Try not to say this. We are there to solve problems. Finding solutions is part of the solving process. It would be boring if we always knew what to do before we started.

“I told you so.”

Don’t say this. This kind of combative language only makes enemies.

“I refuse to do this using basic Javascript, I want to use angular.”

As consultants, we want to guide our clients into making the best decisions possible. Sometimes they do not decide to go with our choices 100% of the time. Hopefully their way works as well. If not, you can mentally pat yourself on the back for the better idea when you end up revisiting your initial concept later on.

“Oops, we deployed the wrong version last night. But we fixed it, I promise.”

“That was an oversight on our part. We have addressed it and will keep it in mind going forward.”

Mistakes happen, and owning up to them is important. But try to do so with professionalism.

“I didn’t accomplish anything yesterday to fix the IE9 issue.”

“Yesterday, I spent the majority of my time researching solutions to the IE9 issue. I am still working on it today.”

When you tell a client you didn’t accomplish anything, they hear that you didn’t do anything. This isn’t true. Sometimes you have to go down a few wrong paths before you find the correct one.

other tips and tricks

  • Have complicated or difficult conversations in person or on the phone first. Then send a summary email. Technical emails have a high risk of unnecessary escalation due to complicated subject matter.

  • Choose your battles wisely. Let them use tabs instead of spaces in their code if they want. But don’t let them write a 100,000-line application in a single class file.

  • Know your audience—always be accurate, but know when to be detailed and when to be general. Talk technical with the former developer-turned-management. Talk concepts with the non-technical project owner who is responsible for the big picture.

  • Be pleasant. If they like you as a person, they will probably like your code better.

  • Identify the stakeholders early on and involve them regularly.

  • Get to know your client before jumping in with both feet. We want to come across as competent but not pushy. Sometimes we have to prove ourselves before we are listened to.

  • Everything mentioned here is a guideline, not a rule.

What technical foot-in-mouth experiences have you had? What should you have said instead? Share your story in the comments.