Good consultants know when to be "invisible"

Sometimes you need to take a backseat to the client team so that they can fully develop the skills they'll need after you're gone. Shannon Kalvar describes becoming an "invisible consultant" in order to allow a client to become the star of the project.
Editor's note: This article was originally published July 11, 2003.

Early in my career, I encountered two schools of thought regarding the consultant's role. One idea is that a consultant should go in and dominate the client's project. The other is that the consultant works in the background with the team to enhance their professional and technical skills. People argue vehemently for one school or the other, but both have a place in the toolkit of the professional consultant. I learned this lesson the hard way, over the course of many years.

Taking the dominant position

I had a chance to work on a massive operations process upgrade for an international client, XYZ Corporation. During the process, I learned a great deal about operations theory and practice, as well as project management and document architecture. After what I thought of as a reasonably successful four-month project, I moved on to my next client.

Two months later, while working on a new network installation, my pager went off a little after 1:00 A.M. When I called back, the party at the other end of the line picked up the phone after one ring. It was Larry, my right-hand man during the operations processes upgrade for XYZ. He had also served as their primary network architect.

He had paged me from home after spending a week trying to come to grips with a professional problem. His boss was unwilling to let him adapt the newly deployed operations methods and tools. He needed some new reports to enhance his capacity management suite, and a handful of the processes' artifacts were not proving to be as useful as we had hoped.

I failed to grasp why he wouldn't just make the changes. When I asked him to clarify that for me, he said, "Steve tells me that I don't really understand the system, so we have to run everything by you guys. Heck. Maybe I don't."

After recovering from my shock, I spent a few minutes chatting with him about inconsequential issues.

How did we get here?

In thinking about Larry's problem, it seemed to me that several issues intersected:

  • During the project, I assumed a highly visible role in the construction of the new procedures and methods. Although Larry worked directly with me for the entire project and came up with at least half of the good ideas, we didn't make any effort to highlight his accomplishments. In fact, we significantly downplayed his contribution.
  • As part of the project, I deliberately mentored the client staff in operational methodology. In fact, I included mentoring as both an action item and a frequent status report accomplishment. But doing that caused their boss to peg them as "learners," not "knowers." I created an environment in which the manager assumed that the fundamental knowledge left with the consultant. His own staff was "second best."
  • In every meeting with senior management, I acted as the team mouthpiece, passing on information and decisions established by the team. Although this allowed the team to benefit from my presentation skills, it also focused the majority of the informal influence-building on me.

All three of these techniques come from the school of heroic consulting -- the gung ho method that states you should go in and dominate your client's project through force of personality and brilliance. You get in front of the client stakeholders and decision makers as much as humanly possible. You demonstrate your worth by being involved with everything all the time. In theory, this improves the client's trust in you so that you gain additional work on the back end.

The heroic consulting model unfortunately produces some ugly side effects. I was now face-to-face with one of the worst: My behavior had undermined the organization's confidence in its own team. The people left behind to run the system were no longer in the privileged position of being the system experts. Instead, they had become subordinate to the "skilled consultant" who helped them.

Larry's last comment that he might not understand it also troubled me. He had designed a good 40 percent of the operation's architecture. He should have known enough about it to make coherent adaptive changes. However, by taking such a prominent lead role, I had marginalized his contributions. That action translated into a lack of commitment on his part; he knew the architecture but was not willing to fight to keep it functional.

Thinking back, did they really need me to go in there breathing fire? The team had the skills it needed to pull off the task. Before the project, their manager trusted them to do the work. I came in to provide specific process and technology-related expertise. Would it have been wiser to follow the so-called "invisible consulting" route?

In "invisible consulting," the consultant works in the background with the team to enhance their professional and technical skills. He helps them with presentations, meeting setups, specific technical issues within his domain, and decision making. His goal is to shy away from direct contact with client decision makers, instead working through the team to accomplish the client's goals. This is accomplished when a client says, "You know, that was a great project. I can't think of a single thing that you insisted we do, but I know you contributed the entire time."

A review of my current situation

I looked at my current network deployment project. The client team had more than sufficient technical skill for the task. They lacked some presentation skills, a modicum of architectural methodology, and a good QA process. But I had lunged into the lead position again.

The next day, I called my client counterpart. We had a frank conversation about the situation, and he agreed that his team could handle the deployment. He also confessed to being uneasy about the amount of trust and influence I had already built in the organization. We both agreed that in the long run it would be best if that influence transferred to his team.

With that in mind, I took steps to become the invisible consultant on the project. I started by calling on him during meetings, then later giving him large sections of the presentations to do. I also coached him in presentation, time management, vision management, and political skills so he could gather the resources to be successful.

I failed my first client by not adapting my consulting style to his political and social needs. I helped my second by taking a step back, setting aside my own ego, and providing him with the tools that he needed to become the star.


Get weekly consulting tips in your inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!

I found the best way to find the greatest consultants is to have them participate in emotional intelligence programs provided by the HayGroup. It helps everyone learn how their strengths and weaknesses will better help them in professional development and working with others on projects.

HAL 9000
HAL 9000

Remaining Invisible to the Upper Management and providing support for the Staff employed there, is the only way you can achieve the successful implementation of any project. If you go in all Gun ho you end up being on constant call for any follow up work necessary and this is generally expected to be Free Advice. Well at least it was when I worked Big Business being the outsider from the Supplier I was always On Call for the slightest problem even though the staff there at whichever company knew their individual Hardware and Software Processes far better than I ever could because I was considered as the [b]"Expert from the Maker"[/b] I was always the first point of contact for the slightest problem. Easy if you finished there a week ago but a total nightmare if the job was a year ago and you had to remember it in all the detail of the deployment. Once I stopped writing any Code I found it much easier to fade into the background and let the staff at the individual companies deal with their Day to Day Operations and not need to constantly be calling me for advice. It is far better to build Self Confidence in these Staff Members than to actually perform the job and they are the ones who recommend you for any further work that is required, so you get called in when actually required and not called just for the sake of calling you for your opinion. Col


When it's not your baby, you don't get to show the baby pictures. (on the good side of that you also don't have to change the diapers) Good post. -d


As a consultant on many projects, I have always remained in the background. My approach is to provide an alternate view of the objectives of the project and how to achieve the goals as set forth in the parameters. I attempt to lead the regular employees to find the right path and let them make the decisions that will allow them to reach the goals they need to reach. I think of it as a helping hand, a leg up or if the goals are quite lofty, to even stand on my shoulders to get to the level required to meet their goals. I'm not there to lead them or guide them but to tickle their intelect and provide different ways of achieving the same goals but by different paths.

Sterling chip Camden
Sterling chip Camden

... you're exactly the kind of consultant that Shannon recommends here. I guess I have kind of a strong personality, and I have to make more effort to back off the lead position. But as I get older, I'm not quite as hot-blooded as I used to be.

Sterling chip Camden
Sterling chip Camden

... and let other people take over. It isn't always an easy thing to do. But it is the best thing -- to create successors for yourself inside your client's organization to carry on your work.

Editor's Picks