In our work lives, we often face drastic changes in the level of our intellectual focus. One moment, we may be working on the details of a specific piece of code, and the next engaged in a conversation about the IT department's code of ethics. Learning how to shift your own scope and to recognize the scope at which other people are working is one of the vital skills of senior consulting.
I was working as a "lone consultant" on a project that my company was thrown off of in midstream. The client allowed me to come in and provide architectural assistance, along with planning and basic project management processes as a courtesy to a mutual C-level friend. At the same time, another large consulting organization sent in free consultants to help "analyze" the implementation.
In the third week, the other consultants held a meeting to discuss implementation costs. I wandered in, trying to finish up a conversation about the sequencing of several server moves during the third phase of the implementation. I wanted to wait for some new switches, while the client engineer thought we could get away with our current network backbone for the initial load.
During the meeting, they analyzed the overall equipment budget for the implementation, which came in at around $12M. I fretted about getting the switches into place before we slammed the new servers with 100,000 users. When the consultants finally asked me for my thoughts, I started worrying about the $1000 or so bill for shipping the switches to the main data center. The rival consultants pounced on my distraction, lashing me publicly for five minutes. Being both distracted and easily embarrassed, I just accepted the abuse.
After the meeting, I retreated to my hotel room to think about what, exactly, went wrong. Although a number of pertinent comments about living in the moment and focusing on the task at hand came to mind, it seemed to me that I could derive another lesson from the experience.
A question of scope of thought
In sober reflection, away from the pressure of the meeting and my previous thoughts, I could easily see that my concern over shipping costs bordered on the ludicrous. Who cared one way or the other about a few thousand dollars when we were talking in general terms about millions?
However, when taken in context with the thoughts that occupied my mind until that moment, the scope of my thoughts flowed logically. I was deliberately working at a highly detailed level, one where the individual elements of specific tasks actually made a difference. At that level of detail, my comments made perfect sense. It was only when they were applied to a different level, looking at a much broader vision, that they became foolish.
That evening, I thought about dozens of similar examples in my life—times when either I had failed to match the scope of my questioner or where other people failed to match my scope. Much to my shame, I realized that I had been just as ruthless as my competitors. When people gave me a response that was more narrowly focused than I wanted, I derided them as small-minded. When the scope of their answers covered things I didn't care about, I thought of them as empty-minded dreamers. In reality, their answers usually made sense within a specific scope—usually one different from mine.
To clearly formalize my thoughts, I came up with two statements:
- "If I do not understand an action, I do not understand the scope which the actor works within." This allowed me to question the scope of the actor without falling into the common ego trap of thinking the actor is simply an idiot.
- "Do I correctly understand the scope behind the question?" I ask myself this question before I open my mouth. When the CIO asks me what I am doing today, he is working in a very different scope than my buddy in the next cube. My buddy might care about the details of my task list; the CIO is generally more concerned with finding out what projects have active workers on them.
Now, all I had to do was figure out exactly what I meant by scope.
Elements of scope
In my thinking, the word scope had a wide variety of meanings. To create a valid analytical tool, though, I needed to clearly identify what the word meant within the framework. That problem kept me up late into the night.
Sometime just before dawn, I came up with the following elements:
- Number of elements: The larger the number of elements being coordinated, the wider the scope and therefore the more general the answer required. This was, in fact, the scope problem resulting in my initial embarrassment. I was concerned with one element (the switches) while my competitors were worrying about the hardware as a whole.
- Number of actors: The larger the number of actors involved, the more general the statements become. The more actors that become involved in answering a question, the less control we have over the answer.
- Number of correlated projects: The greater the number of unique outputs we have to deal with in answering a question, the less detail we can provide in the answer.
- Diversity of elements: When a question's scope deals entirely with one kind of element (for example, financial data), the answer can be fairly compact. However, when a question's scope brings together several contradictory elements (financial data, timing, and ego management), compact answers become inappropriate and misleading.
By questioning these elements of scope, I can usually figure out the right level for a given question or conversation in reasonably short order.
A few years later, I was working with a client who wanted to improve the repeatability of his operations process. As part of my assessment procedure, I spent time talking with each of the team members during their preparations for a massive disaster recovery test.
One of the team members couldn't produce procedures or processes useable by other people. When I talked to him, all of his conversations and thoughts focused on organizing his own actions in time. Within that scope, his efforts made perfect sense. Unfortunately for him, his team and managers were concerned with repeatability and the communication of operational knowledge to third parties. I would like to say that my insight provided me with a way to solve the gentleman's problem, but in truth it just pointed out the essence of the issue. Solving the problem was beyond me at the time.
My insight into the issues of scope allowed me to step back and more clearly assess both my own statements and those of my coworkers. For my own communication, it allowed me to consciously target my statements to the audience's scope of interest. When dealing with my coworkers, it gave me a tool for considering not only the words of their question, but also the context out of which it arose.