Photo by Elena Popova on Unsplash

Yes, I know that’s Go. That’s partly the point. ~Dom

I don’t particularly like chess.

I am reasonably decent at it, although I have never played enough to earn a rating, and I recognize most of the reasons people admire the game. Chess teaches patience and sacrifice, and it teaches the uncomfortable reality that a move can look excellent right now while quietly ruining your position six turns later.

Those are valuable lessons.

What I dislike is how often chess gets elevated into the near-perfect metaphor for strategy. We put chessboards on book covers. We describe great executives, generals, and negotiators as “playing chess while everyone else is playing checkers,” and when we want to communicate foresight, we photograph serious-looking people contemplating knights and bishops. To be fair, chess does require real strategic sophistication.

It also hands the strategist an absurdly accommodating universe.

The board is flat and the terrain is completely visible. There is one opponent, every piece has known capabilities, and every piece moves exactly when and where you tell it to. Nobody misunderstands the plan, and nobody calls in sick. The rook does not have competing priorities assigned by another department, the bishop does not object that diagonal movement falls outside its performance objectives, and the queen does not discover halfway through the game that her access permissions were removed during last quarter’s security review.

Most importantly, the rules do not change. There is an enormous body of established theory precisely because chess is stable enough to permit one: openings have names, positions have been studied for generations, and entire classes of endgames have known solutions. In some situations you can arrive at a board state and discover that someone worked out the optimal answer long before you were born.

Reality is rarely so considerate.

That, I suspect, is why chess is simultaneously useful for learning strategy and dangerous as a metaphor for practicing it. It teaches us to think several moves ahead, but it does not necessarily teach us to ask whether we are looking at the whole board.

The View From 30,000 Feet

There is a family of phrases that appears regularly once people acquire sufficiently senior titles. “I don’t need the details, I need the strategy.” “Let’s stay at the 30,000-foot level.” “Let’s not get into the weeds.”

Sometimes a technical explanation gets cut short because leadership “just needs the business outcome.” None of these is inherently unreasonable. A senior leader responsible for hundreds or thousands of people cannot personally absorb every ticket, transaction, contract clause, and customer complaint; anyone who tried would mostly be demonstrating an urgent need to delegate.

Organizations require abstraction, and information has to be compressed. We build dashboards because executives cannot review ten million transactions, and architecture diagrams because nobody wants a presentation containing forty-seven thousand individual network connections. We summarize projects into status reports because “please read the entire backlog before Tuesday” tends to reduce meeting attendance.

The problem begins when abstraction stops being treated as a tool and starts being treated as a social rank.

Strategy becomes something senior people do, tactics something managers do, and operations something everyone else is responsible for, until the three resemble floors in an office building, with each promotion carrying someone farther from the machinery downstairs.

It is a comforting model, and it is wrong.

Strategy, tactics, and operations are different levels of the same system. Strategy establishes an intended direction, tactics translate that direction into reproducible choices, and operations expose those choices to reality, which, having never attended the strategy retreat, is under no obligation to cooperate.

What gets discovered at the operational level has to travel back upward, because it tells us whether the assumptions embedded in the strategy were ever true. The loop is supposed to close: strategy shapes tactics, tactics shape operations, operations produce evidence, and that evidence reshapes strategy.

Break it, and the organization becomes less informed while believing it has become more strategic.

Strategy Is a Theory

At its heart, every strategy contains a theory about the world.

If we consolidate these systems, efficiency will improve. If we invest here instead of there, the return will justify the opportunity cost. The polished slide at the executive meeting may contain only a few arrows and some pleasantly confident verbs, but underneath those arrows sit dozens or hundreds of assumptions about money, systems, people, and obligations, and some of them are simply wrong.

None of that makes strategy useless, but it does make it conditional, and it changes what execution is for. Execution is where strategy first meets evidence, which is precisely why details matter. Most of them truly do not deserve executive attention, but some detail, somewhere inside the operating environment, may reveal that one of the assumptions holding the strategy up is false.

A company may consolidate several reporting environments to reduce cost, only to learn that one of them carries a control requirement the others don’t. An acquisition integration can be accelerated right up until someone notices that the supposedly minor differences between the two systems encode major differences in how the businesses actually operate. And then there is the ambitious automation target set against a process with so many undocumented exceptions that automating it faithfully would mean recreating years of institutional improvisation in software.

In each case, the strategic objective can remain perfectly sensible while the proposed path toward it becomes impossible.

Finding that out is not getting lost in the weeds. It is learning where the ground actually is.

The Details That Become Constraints

Some details deserve even closer attention, because they do more than describe the current environment; they determine what the organization will be able to do later.

A security permission is a good example.

On the surface, granting someone access looks like an administrative task: select a group, add a user, move on with the project. But authorization decisions have a peculiar tendency to outlive the meeting in which they were made. They establish who can see information and who can change it, who can approve changes (including their own), and who can grant access to someone else. They determine which controls now apply, what evidence future audits will need, what becomes possible if the account is ever compromised, and what future requesters will reasonably expect the organization to repeat.

A tiny checkbox, or a list of territories that compose a team, can quietly become architecture.

Governance works similarly. Governance requirements are frequently treated as something to layer onto a project once the “real work” is finished, on the theory that you build first, move quickly, and figure out the controls later.

Occasionally that works. It also occasionally produces the fascinating discovery that the finished system cannot satisfy the control without substantial redesign, at which point governance is usually accused of delaying the project. This is roughly equivalent to constructing a building and becoming irritated with gravity when someone finally asks whether the foundation can support it.

The requirement did not suddenly appear. It was simply excluded from the model.

This matters because some decisions become progressively more expensive to reverse. A naming convention can be changed, a presentation rewritten, and a small process step adjusted. A deeply embedded architecture, authorization model, contractual commitment, or cross-system dependency, on the other hand, may take months or years to unwind.

A better measure of a detail’s importance is not how small the decision looks, but how much future behavior it constrains, how difficult it is to reverse, and how far its consequences can travel. Chess understands this rather well. Moving a pawn one square is not visually dramatic, but pawns do not move backward, and part of the move’s significance is that the position has permanently changed.

Real organizations contain a surprising number of pawns.

There Is More Than One Board

Chess extends one more generosity to its players: there is only one game. Organizations almost never have that luxury. A company may have hundreds of projects underway at once, all drawing on some shared combination of people, systems, budgets, vendors, data, and deadlines, and a decision that is perfectly reasonable inside one project can be disastrous when viewed across the system.

Suppose Project A needs access to a dataset, so access is broadened and Project A moves forward.

Success, except that the change also weakened a security boundary Project B depends on, created a separation-of-duties concern for Finance, conflicted with an architecture pattern Project C was establishing, and consumed headroom Project D had been counting on. Six months later, an audit team asks why the decision was made, and everyone in the conference room looks around.

Apparently, nobody had needed that level of detail.

This is one of the most common failures of organizational strategy: local optimization masquerading as progress. We ask whether a decision will get the project moving, when sometimes the better question is what else moves when we make it. That question is harder because it forces the decision-maker to acknowledge that the board extends beyond whatever initiative currently occupies the slide deck. The database may be a piece on several boards, and so may the employee, the budget, the customer relationship, and the security group.

Organizations rarely suffer from a shortage of individually rational decisions. They suffer when individually rational decisions interact badly.

Chess teaches us to anticipate second-, third-, and fourth-order effects, and organizational leadership demands one additional skill on top of that: before calculating those effects, determine how many games the move participates in.

Not Every Detail Matters

There is an obvious counterargument to all of this, which is that leaders really can get too deep into the details.

Micromanagement is real, and senior executives can waste extraordinary amounts of organizational energy inserting themselves into decisions that should have been delegated three levels below. Anyone who has watched a room full of experienced professionals wait while an executive debates the precise shade of blue on a slide has witnessed hierarchy achieving its purest form.

So the answer cannot be that leaders should know everything. They can’t, and seniority shouldn’t imply retaining detailed expertise in every discipline that eventually reports through someone; in any sufficiently complex organization, that is impossible. What the job actually requires is selective depth, meaning the judgment to recognize when an abstraction is sufficient and when it is time to descend another level.

Sometimes the right answer really is, “I don’t need the implementation details. You understand the objective; use your judgment.” That can be excellent leadership.

Other times the right response is, “Wait, explain that part again,” followed by the questions that tend to matter most: who else depends on this, whether it can be reversed, what access or control it touches, what we are assuming, and who carries the risk if we’re wrong. Those questions are strategic even though their answers are full of details, because the answers determine whether the strategy remains sound.

The distinction is subtle but important. Seniority should not reduce curiosity; it should improve the ability to aim it.

Compression Without Ignorance

The higher someone rises in an organization, the more their understanding of reality is mediated through other people (recently discussed here). Analysts summarize data, managers summarize operations, and architects summarize systems, while finance, security, legal, and project teams each summarize their own slice of performance, risk, obligation, and progress.

By the time information reaches the top of an organization, reality has usually been compressed several times over.

That is necessary, but every compression algorithm loses something, and the important question is whether what gets discarded is actually noise. An executive dashboard might show a project as green, which may be an entirely accurate picture of schedule and budget while saying nothing about the security exception required to keep it that color.

A milestone can be truthfully reported as met on schedule even though meeting it consumed resources another initiative had already planned to use.

None of these statements needs to be dishonest. The abstraction can be completely accurate and still conceal something strategically important.

The map does not need to lie to mislead you. It only needs to omit the feature you eventually drive into.

Authority and the Right to Not Know

There is also an ethical dimension here that organizational language tends to step around. Authority and knowledge have an unusual relationship: as someone’s authority increases, their ability to affect systems grows, while their direct contact with those systems usually shrinks.

A frontline employee’s poor decision affects a transaction and a manager’s affects a team, but a senior leader’s can alter policy, architecture, funding, priorities, or access across the entire organization. The blast radius grows precisely as the information becomes more abstract. That ought to make us more humble about what we don’t know.

In practice, it often makes the details feel beneath us.

No leader can reasonably be expected to know every dependency a decision affects. They can be expected to create conditions in which material dependencies are allowed to surface. “I didn’t know” can explain an outcome, but it becomes a much weaker defense when the organization tried to explain and was told leadership didn’t need the details.

Decision authority carries responsibility for the intended result, as well as for the reasonably foreseeable consequences of how the decision was made.

Sometimes progress on one project creates a cost somewhere else, and security, operations, another project, a future team, or a customer inherits it. The dashboard stays green because the problem moved outside the boundary of the dashboard.

There is a difference between solving a problem and successfully transferring it to someone who was not in the meeting, and strategy should know the difference.

The Pieces Do Not Always Move

This brings me back to chess.

One of the lessons people praise most about the game is the discipline of thinking ahead: consider the response to your move, then your response to that response, then the position that emerges several turns later. That habit is valuable far beyond the board, but reality demands something harder.

The terrain is uneven, the information is incomplete, and the rules can change mid-game. The opponent may not be singular, obvious, or even hostile.

Most importantly, your pieces have agency. They carry incomplete information, pursue objectives that aren’t quite yours, disagree with one another, and eventually just get tired. Some of them know something you don’t, and occasionally one of them is trying very hard to tell you that the square you intend to move onto is not actually part of the board.

This is why effective strategy cannot live entirely at altitude.

The strategist has to move vertically through levels of abstraction, rising high enough to see the system, descending far enough to understand the constraint, and rising again carrying better information. That movement is strategic thinking in its own right. The leader who refuses to descend because the details are “operational” may not be maintaining strategic altitude at all.

They may simply be protecting the strategy from evidence.

The Board Is Not Flat

I still understand why we like chess as a metaphor. It gives strategy an appealing elegance: a board, a set of pieces, an objective, and consequences for every move. It creates a model where thinking farther ahead than the other person might be enough to win.

There are worse lessons to perpetuate.

But organizations are not chessboards. The ground is uneven, the pieces have opinions, there is rarely only one game in motion at a time, and the information that determines whether a brilliant move succeeds may arrive disguised as an inconvenient technical detail from someone several layers below the person making the decision.

Senior leaders do not need to know everything, and that has never been the standard. What they need is harder: enough understanding to recognize which details can invalidate the strategy, enough curiosity to ask what else moves and which decisions will constrain future options, and enough humility to notice when the abstraction in front of them has compressed away something important.

Above all, they need to understand that authority does not grant the right to declare consequential details beneath one’s level.

Chess teaches us to think several moves ahead, but real strategy asks for more.

Before deciding what move comes next, we have to understand the terrain, the rules, the other games already in motion, and the pieces whose behavior cannot be reduced to symbols on a board. In the real world, the most dangerous strategic mistake is not always choosing the wrong move.

Sometimes it is believing you understood the board.