The first thing a consultant needs to learn is how to give advice.
My very first ‘real’ consulting engagement was helping a client implement a structured wiring system for their multi-campus organisation. If you know anything about network cabling systems, they rely on local ‘hubs’ – rooms that the cables run from to the individual desktops where devices would be plugged into a terminating outlet. Now, I had done this before in previous roles, but in those cases, the hub locations were already selected. I was now expected to make the decision on where to locate the hubs. I actually had no idea where the hubs were best located in a building. I knew the technical parameters – maximum cable runs of 90m – but that was it. So, I asked one of my senior colleagues, ‘how do I do this?’ His reply set me up for a career as a consultant: ‘Just make a decision. That’s what the client is expecting.’
I had been engaged as an ‘expert.’ I just needed to act like one. Confidence, logic, and bluster. And a willingness to discuss and change my mind if warranted. In this situation, I got hold of the Cat-3 cabling standard, read it backwards and forwards to reinforce my ‘expert’ status. I also learned I only needed to be a couple of pages ahead of my client on pretty much any topic to be seen as an expert.
While I honed my craft over the years, that was a key lesson for me in how to give advice.
Another engagement saw me involved in the design of a major corporate network. This was the early days of rolling out large-scale wired LAN solutions for companies. Some firms were moving from serial bus cabling solutions (using fat coaxial cables) like ARCNet, Token Ring and Ethernet to the structured twisted-pair solutions (basically Ethernet over twisted pair became the standard at that point). Some organisations had no networks, so were greenfield sites. Every networked device in an office needed to plug into something at the hub – typically a ‘concentrator’ that had dozens of ports for connections to the upstream corporate network. At the time, not all of these devices from different vendors spoke to each other correctly (they were not able to be interconnected, even if they were strictly compatible with the published standards). Selecting a technology supplier was critical to having a cost-effective solution. It was my job to lead the selection of the vendor/s to work with. It was, in the early 1990s, a multi-million-dollar decision for my client.
I pored over the equipment specifications from the competing vendors, set up ‘bench tests’ to look at ease of use, construction quality, and interconnectivity, and trialled various other aspects of the overall network solution we had designed. Some critical components of any successful solution were the ability to connect to mainframe hosts and UNIX servers, use ‘dumb’ terminals and PCs, and support Novell, TCP/IP, and (as-yet unreleased) OSI protocols. What we were asking for was, essentially, unique. As in never done before.
After about six months, the decision came down to two vendors. I favoured one; the project manager (to whom I reported) favoured the other. I talked to everyone I knew who might be able to help critique the two vendor solutions. I even flew to the US (self-funded) to talk directly to some of the Silicon Valley vendors, by-passing their local New Zealand agents. I attended the major networking trade show of the time in Dallas for additional ideas and input. This was an important decision, and I treated it very importantly.
I genuinely couldn’t understand why the other solution was preferred over the one I favoured. I got frustrated. I got emotional. I was certain the organisation was about to make a fundamental mistake.
Consulting lesson #2 came from the personal assistant to the project manager. ‘Don’t get emotional, don’t get over-involved. After all, you are *only* a consultant.’ And she was right. As a consultant I needed to ensure I had perspective. I needed to be able to stand back and actually care less. I needed to be objective.
In taking that on board, it lead me to another key learning: It wasn’t necessary to focus on the best solution. It was enough to have a good enough solution. Perfection is subjective, unattainable, and typically the more expensive way forward. In this case, my favoured solution was overkill. Once I stepped back, took away the emotion, getting past the selection and onto implementation was easy.
To be an effective consultant, you need to be on the lookout for these types of learnings. In other words, you need to be able to not just give advice, you need to be able to take it as well.