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!