Top Tips for Providing Successful Tech Advisory Work

What is it like to work for a tech consulting company? What can you expect your job to look like as a tech consultant? As a tech consultant, I have worked on multiple projects that I’d classify as primarily advisory work. These engagements are more focused on answering questions than delivery software.

Let’s explore the theme of advisory engagements, the format of deliverables, the type of teams and timeframes, and what to expect if you are the consultant on the advisory project.

Theme: Advisory engagements are usually short with a few amount of people who have a core question or two. An advisory consultant will provide research and conclusions, rather than providing working software. In my experience, questions include, “Can your company provide ongoing support for our application?”, “Is our software system viable?”, “What would it take to upgrade from X to Y?” These questions may result from lack of in-house expertise or because they want a second opinion.

Varying Deliverables: The format of the deliverable at the end of the engagement is tailored to the wants and needs of the client. I’ve had clients request written analysis dozens of pages long, presentations to executives, work plans created in their tracking system (Jira for example), etc. Go with whatever format is requested; it is the content and answers that are most important rather than format.

Restrictions: It’s important to note there is a limit to what can be done in a typical advisory engagement. They’re generally done by 1-2 people for a small number of weeks. You won’t have time for a full onboarding process, so many questions about their business and use cases will remain unanswered. Also, you may get no access to certain resources, systems, or key people during this time. People have vacations, and sometimes getting approved for access to things take time.

Intro to the company: Often an advisory engagement is the first time a client works with a particular tech consultant. As such, in addition to getting their questions answered, they also end up forming an opinion on how the consultant company works. When you do a great job, they often end up calling for more work for custom software development. It’s important to make a strong lasting first impression.

If you end up helping an advisory engagement in the future, here are some tips:

Ask for as much as you can, as soon as you can: Given limited time, you want to hit the ground running as much as possible.  You should front-load requests for access to the things & people you’ll need to do the best job possible.  It’s unlikely all your requests will come through, so do the best you can with what’s made available.

Ask for, set and clarify expectations early & often: Find out and agree on the key questions that underly the engagement What are the necessary deliverables?  When are they needed, and in what format?  Do they need to go through reviews along the way, who will conduct those?

Start digging: Use everything and anything you have available to you. You may have to use tools you haven’t before, so be flexible and take a learning opportunity. Often clients will have tools they don’t know how to use most effectively, leverage these for good results.  Application Performance Monitoring tools, cloud consoles, CI/CD systems and code analysis tools may be available to you and can often be helpful in making sense of what’s there.

Be truthful: Usually, the client stakeholder will be genuinely curious on the answer to the key question. Other times they have revealed they have a desired answer they wish us to deliver.  My advice in that scenario is to remain unbiased in the research and deliver what you understand to be the truth of the matter.

Over communicate: It’s important to deliver the message of how things are going. Repeat the limitations you’re dealing with, call out assumptions you’ve made, caveats and workarounds that have become necessary to move forward. Hopefully the client stakeholders can help issues get resolved soon, and at the least, the client will know what stones have been left unturned. Hold a daily standup with client oversight person to facilitate this communication.  That way there is an easy way to touch base. Also, hold a weekly or more often catch up with your firm’s stakeholders, so that they may help in escalating issues or give advice on any tricky situation that may arise.

Beware of rabbit holes: While researching one question, more questions often reveal themselves. A client may ask what it would take to upgrade to a modern version of a library.  Along the way, you may discover they have built a custom application framework on top of an out-of-support web framework. When you bring this up, it’s natural for them to ask: What would it take to replace/upgrade that too? While this is a good discussion to have, it’s also important to keep in mind that it can turn into “scope creep” and keep in mind the limited people and time available to answer the original questions. Discuss this with relevant stakeholders and decide to keep the new questions unanswered, to add time to investigate them later, or to otherwise change course.

Visualize: Creating graphics or tables of data can be helpful to deliver your message in an effective way.  There are many useful tools for this. I’ve used Lucid Chart for application architecture diagrams, drawio.com is good especially for security-related topics, yuml.me/diagram/scruffy/class/draw is great for dependency graphs or sequence diagrams, and so is https://mermaid.js.org/.

Also, get creative with tools you know to bring the problem at hand to bear. Once, a client brought a large set of repositories and wanted to know what they were and how complex it was. I used command line tools to load file names, extensions, and line counts into a local database and used SQL to analyze the top line counts and file counts by file type. That gave a basis to the show what were the major languages and tools in the project, by sheer bulk.

You may think that as a software engineer, this may not apply to you. But guess what? I am myself a software architect at SPR, with a generalist style, full stack experience in software engineering. I've worked in many different programming languages on web and mobile and in front end or back end or data applications. While advisory engagements aren’t the core of my role, it does happen occasionally. If you find yourself asked to perform this work, it's good to be prepared with these themes and advice.