The idea behind this month’s article comes from the soccer pitch again. I was working with my goalkeepers during a session covering breakaways, and I started by asking them, “Do strikers tell us when they are going to shoot the ball?” The answer I always get is a resounding “No!”
That answer is both correct and incorrect. While I would love it if a striker outright announced, “Hey goalkeeper, I am going to shoot the ball into the lower-left corner of the goal,” they obviously do not speak those words. However, their body language and posture communicate a wealth of information. I constantly tell my goalkeepers that they must learn to read the game and read the players.
You might ask, “This is great, James, but how does this relate to technology?” Let me ask you: does your projector ever tell you, “Hey tech manager, I am going to go out of focus today”? Or does your microphone say, “Hey, get ready for some loud audio feedback”? No, devices do not speak to us directly … or do they? When monitoring a microphone, we can observe speaker audio levels, inspect mic placement, and determine with high confidence whether feedback is imminent. As tech managers, we must be able to read our environment, which means deeply understanding our equipment, physical spaces, and end users.
Knowing our equipment, environment, and users allows us to evaluate multiple variables simultaneously. By “knowing our equipment,” I do not mean memorizing every feature and setting, but rather understanding what our technology can and cannot accomplish. The same principle applies to our physical spaces: we are in and out of these rooms daily, understanding screen positioning, ambient light sources, and acoustical surfaces. When it comes to our users, we recognize who prefers a simple, streamlined setup versus who is tech-savvy, as well as who might be hesitant with technology compared to those who dive right in without assistance.
We can synthesize all of this contextual data the moment a service call comes in. For instance, suppose a call originates from Classroom A, assigned to Professor X. We know Classroom A features a standard lectern setup with a projector and computer input. We also know Professor X is an expert in their academic field who struggles with room controls, uses no audio, and only presents slide decks. Recognizing this pattern, we can reasonably anticipate that Professor X simply needs the display powered on and the correct input selected—allowing us to proactively power up the room remotely while taking the call.
Conversely, if Professor Y calls from the same room, knowing they are one of our most tech-comfortable users who rarely asks for assistance, we can reasonably suspect that a technical failure has occurred and dispatch a technician before even picking up the phone.
Admittedly, reading these situational cues is not 100% foolproof, but it can help us respond more effectively—a massive operational win. Even when our initial assumption is off, our proactive actions in these examples carry minimal risk. If Professor X actually wanted the document camera instead of the laptop input, the display is already powered on, making the pivot effortless. If Professor Y simply locked their user account, we can quickly recall the dispatched technician while completing the account unlock.
