Chapter 35: Multi-Dimensional Tetris

Last updated on 
Share
Chapter 35: Multi-Dimensional Tetris

The Wise Owl Fallacy

There is a classic fable about a mouse asking a wise owl how to stop being hunted by hawks. The owl thinks for a moment and says, "Become a hedgehog. Nobody eats a hedgehog." When the mouse asks how to turn into a hedgehog, the owl replies, "I handle the strategy; tactics are your problem."

A Project Manager who lives exclusively in high-level strategy without understanding tactical reality is that wise owl.

To manage a project unit effectively, you must operate on multiple horizons simultaneously: immediate operations (days and weeks) alongside structural strategy (months and years). Delegating authority does not mean abdicating operational control or forgetting how the gears fit together on the ground.

The One-Dimensional Swap vs. The Multi-Dimensional Board

Consider a standard project unit structure:

  • Project Swallow: Led by Senior Lead Sem, supported by Mid Developer Ivan and Junior Developer Maria.
  • Project Sparrow: Led by Senior Lead Inna, supported by Mid Developer Harry and Junior Developer Olly.

Suddenly, external reality hits: Project Sparrow’s client cuts funding. The project is winding down, requiring only one person for maintenance before closing in two months. Meanwhile, Sales secures a new initiative—Project Nightingale—which needs two people today and a third person in two months.

The naive, one-dimensional solution is simple math: take two engineers off Sparrow and drop them directly onto Nightingale.

A real Project Manager treats this as a multi-dimensional Tetris. Every move changes team stability, risk exposure, and career trajectories.

Evaluating the Board Positions

When deciding who stays on Project Sparrow for maintenance and who moves to Project Nightingale, you evaluate trade-offs:

  • Leaving the Junior (High Risk / High Opportunity): Leaving Junior Olly alone on Project Sparrow is risky. However, if the support scope is simple and Olly is eager for ownership, it acts as a controlled test of his autonomy.
  • Leaving the Mid (Stepping-Stone Growth): Leaving Mid Harry on support works well if he prefers execution over management. The Project Manager handles client coordination while Harry manages the code, slowly easing him into client-facing responsibility.
  • Leaving the Senior Lead (The Lone Expert): Leaving Lead Inna alone on support removes her management workload. It can be a relief if she is burnt out on team oversight. But keeping a Senior Lead tied to a dying project long-term risks wasting expensive capacity and creating isolation.

If Mid Harry moves to Project Nightingale and takes over as lead, dropping Lead Inna onto Nightingale two months later will create friction—two Senior Leads on one project competing for authority. You must anticipate this conflict before making the first move.

Fractional Allocations and Bus-Factor Protection

Partial allocation across projects is a valid operational solution—especially for maintenance streams. If a single engineer handles support alone and suddenly gets sick or resigns, the resulting service gap can severely damage company reputation. Distributing half a Lead and half a Mid or Junior across two projects mitigates single-point-of-failure risks.

However, context switching carries overhead. A human is not a light switch; flipping between codebases, environments, and clients burns time and mental energy. This switching cost hits technical and creative team members hardest, as their work relies heavily on staying in a deep flow state. Use fractional allocation deliberately to protect continuity, but factor in the tax on productivity.

Looking Across the Entire Board

The biggest mistake a manager can make during a reshuffle is looking only at the affected projects (Sparrow and Nightingale).

A structural change on one side of the team is your best opportunity to fix long-standing organizational debt on the other side (Project Swallow):

  • Is Mid Ivan on Project Swallow ready to step up to a Lead position?
  • Is Senior Lead Sem exhausted from his current codebase and ready for a fresh technical challenge?
  • Has Junior Maria outgrown simple tasks and needs exposure to Project Nightingale's new architecture?

When context shifts—when projects end, clients pivot, or budgets change—do not just ask, "How do I find work for these idle people?" Ask: "What hidden operational problems or opportunities across the entire unit can I solve with this single reshuffle?"

Using a single structural move to fix multiple career, burnout, and delivery bottlenecks turns basic resource scheduling into strategic team engineering.