Basic Concept #31: Play the board, not the last move

I learned this lesson during what should have been a routine technical discussion but became a masterclass in organizational dynamics.

I’d proposed a significant refactoring of our core authentication system. The current implementation was brittle, hard to maintain, and causing security vulnerabilities. I’d spent weeks analyzing the codebase, designing a cleaner architecture, and building a comprehensive proposal with timelines, risk assessments, and migration strategies.

During the code review meeting, one of the senior developers, Mark, immediately jumped on a specific implementation detail. “This approach will cause performance issues,” he said. “We can’t afford the latency overhead in our authentication flow.”

My immediate instinct was defensive. I’d done performance analysis. I had benchmarks. His concern was based on outdated assumptions about the framework we were using. So I responded immediately, pulling up my performance data and explaining why his objection wasn’t valid.

But Mark doubled down. He questioned my testing methodology. He raised concerns about edge cases I hadn’t considered. Soon, other developers were chiming in with their own technical objections. The meeting devolved into a detailed technical debate about implementation specifics.

I won most of the technical arguments. My data was solid, my architecture was sound, and my responses addressed their concerns effectively. But by the end of the meeting, there was no consensus to move forward. The proposal was tabled for “further analysis.”

Later, I learned what had actually happened. Mark wasn’t concerned about performance, he was concerned about timeline. He was leading a critical feature release and couldn’t afford to have key developers pulled away for a major refactoring project. But he couldn’t say that directly without appearing to prioritize his project over system security.

Instead of engaging with his stated technical concern, I should have recognized it as information about broader organizational dynamics. The real issue wasn’t authentication performance, it was resource allocation, project timing, and competing priorities.

I was playing the last move (defending my technical approach) when I should have been playing the board (understanding the resource and timing concerns that were driving the resistance).

That expensive lesson taught me: every workplace interaction is part of a larger strategic game. When you react to the immediate move, you miss the broader patterns that determine the real outcomes.me that matters.