Spotters Save More Than Reps

Spotters are often seen as the quiet figures standing near the bench or squat rack, but their role is anything but passive. A good spotter wears many hats: a safety net ready to intervene if failure would cause harm, a form checker watching for breakdowns in technique, a source of subtle cues like “tighten up” or “drive through.” Yet the essence of a spotter’s job is restraint. They give just enough help, if any, to let you challenge yourself safely and build real strength.

“A spotter’s purpose is to help you lift, not to lift for you.”

This same principle shows up in the best peer reviews. When a teammate reviews your code, design, or plan, they are not there to rewrite your work. Their goal is to provide insights you might have missed, highlight potential risks, and offer alternative perspectives. Done well, a review leaves the author better prepared to own and improve their work, not dependent on the reviewer to fix it. The best peer reviewers, like the best spotters, are vigilant but hands-off until needed.

Similarly, in product work, the feedback we gather from users should act like a spotter’s cues. Engaged users tell us what is confusing, what is delightful, and what is missing, helping us see where to focus. But they do not dictate the solution. They guide our decisions with their lived experience. If we lean too hard on user feedback as a script, we lose our strategic intent. Like a lifter expecting the spotter to lift every rep, we stop growing.

Even in the boardroom, we do not go in cold. Before a major strategy session or executive presentation, we run documents by trusted colleagues and dry-run meetings to anticipate hard questions. These are forms of spotting. The spotter’s goal is the safety and growth of the lifter, not their own performance — and the same is true of the colleagues who review your work.

Skipping spotters by rushing in without preparation is like dropping the weight in front of your peers. You overlook a key stakeholder’s concern, fumble a critical metric, fail to align on goals.

The risks of skipping spotters are real, both in the gym and in our work. Attempting a near-max squat without a spotter or safety pins risks catastrophic injury. Likewise, shipping straight to production without a second set of eyes can let bugs, security flaws, or critical oversights slip through. Even when alone, you can set up tools like spotter arms or safety straps in lifting, and automated linters or security scans in software, to catch failures before they cause damage. These tools do not replace human judgment but add a crucial layer of resilience.

This watchful mindset extends to active and adversarial roles like red, blue, and purple team exercises in security. Here, the spotter is not quietly observing but actively challenging the system. Red teams attack assumptions and infrastructure to expose weaknesses. Blue teams defend and shore up vulnerabilities. Purple teams integrate both perspectives to accelerate learning. The spotting role becomes dynamic and strategic, applying deliberate stress so the team grows stronger, smarter, and more resilient before a real adversary arrives.

“Great spotters know when to speak up, when to stay silent, and how to encourage without undermining.”

To be a better spotter — in the gym, on your team, or in the boardroom — focus on staying attentive, offering clear and timely feedback, and resisting the urge to take over. Remember, you are not there to lift the weight, give the presentation, or write the feature. You are there to assist, protect, and create the conditions for someone else to succeed. As explored earlier, a key aspect of strong product management is defining the why, not prescribing the how, empowering engineering teams to discover innovative solutions rather than trying to do the lift alone. Above all, great spotters listen deeply, because understanding what someone needs in the moment is the difference between helping them grow and accidentally holding them back. And listening, both as a skill and a form of strength, is exactly what we will explore in the next chapter.