Board ↔ Meeting Alignment explains how board structures and meeting systems co‑evolve to shape each other.
Core Question: How do board and meetings serve each other?
Board → Interactions reads the board to derive interactions. Interactions → Board ensures interaction outcomes flow back onto the board. Both work at the level of individual Interactions. Board ↔ Meeting Alignment zooms out: how does the board as a whole shape which meetings exist, and how does the meeting system as a whole shape what the board looks like?
The board's structure implies certain meetings: columns suggest handoff points (which need coordination meetings), swimlanes imply parallel streams (which need sync meetings), and item types require different processing (which need different meeting formats). Conversely, what happens in meetings shapes how the board evolves: standups reveal what needs to be visible, planning sessions expose structural gaps, retrospectives generate improvement items.
Details
Co-Evolution as System Design
The alignment works in two directions simultaneously:
Board structure → Meeting system:
- Column structure reveals handoff points → Handoff Meetings
- Swimlanes reveal parallel streams → Coordination Meetings
- Item types require different processing → Specialized Meeting formats
- Flow patterns reveal rhythm → Meeting Cadence
- Dependency structures reveal connection points → Dependency Meetings
Meeting system → Board design:
- Standups reveal what must be visible → Visibility requirements on the board
- Planning sessions expose what needs structuring → Structural requirements
- Refinement reveals readiness needs → Readiness columns or criteria
- Retrospectives generate improvements → Improvement tracking on the board
- Cross-team syncs surface dependencies → Dependency visualization
The alignment check: Where do interactions hide between the columns? Are they visible enough? Does the current mapping of interactions-and-meetings make the value stream clearer — or does it obscure it?
Practical Examples
The board that creates its own meetings: A team sets up an FL2 board with columns for Explore, Commit, Build, Review, and Deliver. Reading the board structure reveals: Explore→Commit needs a decision meeting, Build→Review needs a quality handoff, and the overall flow needs a standup. The board's column structure literally dictated which meetings were needed — and each meeting's outcomes change what moves on the board.
The meeting that reshapes the board: A weekly sync between two teams keeps surfacing integration issues. Applying Board ↔ Meeting Alignment reveals: there's no dependency column or integration lane on either team's board. The meeting is compensating for missing board structure. Adding an explicit integration lane makes dependencies visible before the sync — the meeting can then focus on decisions rather than discovery.
Smells — When to Look Closer
- Board and meetings designed independently by different people — structural disconnect is almost guaranteed
- Changing the board without asking "which meetings does this affect?" — one-sided evolution breaks coherence
- Adding meetings without asking "where does this show on the board?" — invisible interactions can't be improved
- Treating the board as "the truth" and meetings as secondary — the board is a model, not reality; both need each other
Related Patterns
- Board → Interactions and Interactions → Board work at the Interaction level; this pattern works at the system level
- Interactions Network shows the connections between meetings that this pattern helps align with the board
- Categories provides additional lenses for checking coherence
Your play!
If you want to use this in your worksystems-design sessions, here is all the material you need.
More about this
These patterns are part of the Flight Levels thinking and design model. If you want to learn more, take the Kick start path to Flight Levels Now!