Stacking and Blocking

Stacking decides who gets which floor; blocking decides what sits where within it — and together they determine whether the interdependency evidence gathered in Diagnose becomes lived adjacency or archived intention. A concept can be strategically sound and fail in the stack: interdependent teams separated by four floors collaborate by calendar invitation, customer zones bleed into confidential work, and the organisational identity the concept promised is contradicted by who ended up in the basement. This method makes the allocation an evidence-driven model with explicit trade-offs, not a floor-plan negotiation won by seniority.

• In Develop, once the concept is confirmed and sharing ratios set capacity per population
• In portfolio scenarios, run per building to test which distribution logic each asset supports
• Re-run in Recalibrate when reorganisations, growth or ratio changes invalidate the current stack

• Strategist and spatial analyst modelling the stack
• Architect testing distributions against building reality
• Business unit leads validating adjacency consequences — after the model exists, not before
• FM and security for operational and secure-zone requirements

• Interdependency matrix and adjacency requirements from Business Needs Interviews
• Confirmed concept: zoning logic, neighbourhood structure, shared amenity strategy
• Capacity per population from Sharing Ratio
• Building constraint register: floorplates, cores, services, accessibility, structural limits
• Separation requirements: confidentiality, security, regulatory, acoustic
• Customer-facing and hospitality zone requirements

1. Convert the interdependency matrix into adjacency priorities: which team pairs carry evidence-backed adjacency requirements, at what strength, and which carry separation requirements.
2. Model candidate stacks against the priorities: distributions of populations across floors scored on adjacency satisfaction, separation compliance, and capacity fit per floorplate.
3. Block within floors: neighbourhood placement, shared amenity positioning, customer-facing zones, secure zones, and the circulation logic connecting them.
4. Test each candidate against building constraints: floorplate geometry versus neighbourhood size, vertical circulation versus cross-floor interdependencies, services capacity versus specialist settings.
5. Position shared amenities strategically: amenity placement is connection infrastructure — a shared floor between interdependent populations does adjacency work that stacking alone cannot.
6. Confront the identity dimension explicitly: what the stack communicates about status and priority, and whether it contradicts the concept's stated identity. The basement question is a strategy question.
7. Score candidate stacks, present the trade-offs (every stack sacrifices some adjacency), and route the decision through the governance structure — not through the loudest business unit.
8. Document the selected stack with its adjacency satisfaction record and known sacrifices.

• Seniority capturing the stack: top floors allocated by hierarchy against the evidence — name it as the identity decision it is
• Adjacency requirements from Diagnose quietly downgraded to preferences under floorplate pressure
• Cross-floor 'adjacency' treated as satisfied — vertical separation is separation; stairs are a behaviour, lifts are a barrier
• Secure and confidential zones placed last and squeezed, creating compliance retrofits
• Growth allocated nowhere: a stack at 100% capacity on day one has already failed the selected scenario

• Selected stacking and blocking model with adjacency satisfaction record
• Known-sacrifice register for unsatisfied adjacencies
• Zone plan: neighbourhoods, shared amenities, customer-facing, secure
• Growth and flexibility allocation
• Constraint conflicts escalated to portfolio or design resolution

The stack structures the Kit of Parts distribution (which settings on which floors) and Architectural Guidance zoning. The adjacency sacrifice register enters Recalibrate's monitoring: unsatisfied adjacencies predict where collaboration friction will surface. Because the model lives in the platform, reorganisations regenerate the stack against the same evidence rather than triggering ad-hoc moves.

The model scores adjacency satisfaction; it cannot decide the identity questions — who visibly gets what, and what that placement communicates. Nor can it navigate the politics of telling a business unit the evidence puts them on floor two. Judging which adjacency sacrifices are absorbable and which will become organisational grievance is experience the scoring informs but does not replace.

• Stacking by org chart and seniority, then decorating with adjacency language
• Treating the interdependency matrix as advisory once floorplates get difficult
• Ignoring vertical separation costs in adjacency scoring
• No growth allocation, converting the first reorganisation into a full re-stack
• Letting business units negotiate the stack bilaterally, dissolving the evidence into a land settlement

A bank consolidating three buildings into one modelled four stacks. The evidence-optimal stack placed trading-adjacent risk teams on the trading floor's level — displacing the executive floor tradition. The identity question went to the leadership team as an explicit decision: they chose the evidence stack, relocating executive space to a mid-building shared-amenity floor. The recorded reasoning — 'the stack should serve the work' — became one of the concept's most quoted principles, and the sacrificed adjacency (marketing to product, one floor apart) was flagged for Recalibrate monitoring.