Scaling work management across teams and use cases
Scaling work management across teams and use cases
This domain tests operating-model design: how to standardize without freezing teams, and how to roll up work across boards and workspaces.
Core rules
- Organize by stable boundaries: workspaces for business units or functions, folders for portfolios or programs, boards for teams or projects. A workspace is a sharing and admin boundary; do not use one mega-board for unrelated teams unless the work truly shares one lifecycle and permission model.
- Standardize the shared schema, not every column: common status labels, people and date columns, item ID, and a consistent connect-board pattern. Let teams add local fields. Publish board templates and a naming convention so new boards are comparable.
- For cross-team reporting, create a portfolio board or dashboard that connects to team boards. Use Connect Boards to link items and Mirror columns to display status, budget or dates. Mirror data is read-only; the source board remains the system of record.
- Scale governance with workspace admins, named board owners, content directory, template ownership and periodic archive reviews. Track automation and integration quotas because usage grows with boards, not just users.
- Choose the use-case pattern: campaign management, product launch, client onboarding or IT requests each need different groups, approval steps and reporting. Reuse the pattern; do not clone a board and let its schema drift.
Worked example
Five regional teams each run a project board. Create a Portfolio board in a shared workspace, add a Connect Boards column to each regional board, and mirror Status, Budget and Target date. Build a dashboard with a global Region filter and a chart of budget by status. Reasoning: each region keeps its own board and permissions; the portfolio provides a single rollup; mirrors avoid copying updates. If a region needs a different approval path, keep that local and mirror only the shared fields.
Traps
Cloning boards without a template owner creates schema drift. Connecting one portfolio item to many projects can double-count mirrored budgets in sums. A single board for every team creates permission conflicts and unwieldy automations. Forgetting automation quotas and orphaned integrations at scale is a common governance failure.