> For the complete documentation index, see [llms.txt](https://guides.tability.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guides.tability.io/docs/become-a-tability-power-user/how-tos/how-many-plans-do-you-need.md).

# How Many Plans Do You Need?

Once teams know[ how to create a plan](https://guides.tability.io/docs/become-a-tability-power-user/features/plans/creating-and-editing-plans-and-sub-plans), the next question is almost always: how many should we actually have? Do we need one for the whole company, one per department, one per team — or can everything just live in one place?

There's no single right number, but there is a right way to think about it: a plan should map to a group of people who would sit in a room together to talk about those goals. If a group meets to discuss a set of OKRs, that's a plan. If they wouldn't, it probably shouldn't be bundled into one.

### Structure plans around how your org actually works

Most teams land on one of a few common structures, and the right one depends on how your organization sets goals — not on a "correct" number of plans:

* Company + departments. A top-level company plan with departmental plans underneath (Sales, Marketing, Engineering, Finance, and so on). This works well when goal-setting flows top-down from company priorities.
* Business units. If your company operates as several distinct units rather than shared departments, each unit gets its own plan, sometimes with team-level plans nested below.
* Big rocks or initiatives. Some companies organize around a handful of cross-functional priorities for the period ("Launch Product X," "Expand into Region Y") rather than by department at all.

Whichever structure you pick,[ sub-plans](https://guides.tability.io/docs/become-a-tability-power-user/features/plans/creating-and-editing-plans-and-sub-plans) let you nest them — a company plan can contain department sub-plans, which can contain team sub-plans — so the hierarchy in Tability mirrors the hierarchy of how goals actually get discussed.

### Don't fight silos by merging plans — link goals instead

A common instinct is to avoid cross-team silos by cramming everything into one giant plan so nothing gets missed. That usually backfires: one plan with every team's goals in it becomes noisy and hard for any one team to focus on.

The better fix is[ linking goals](https://guides.tability.io/docs/become-a-tability-power-user/features/outcomes-key-results/outcome-relationships) across plans. A key result in a department plan can roll up into a company-level objective, or show a dependency on work happening in another team's plan. That gives you the visibility you were trying to protect against silos, without forcing every goal to live in the same place. Keep plans focused; use relationships to connect them.

### Need different timelines in the same plan? You can't — but you can fake it

Every plan runs on a single timeline, so you can't mix a quarterly goal and an annual goal in the same plan. If you need that, the goal needs its own plan with its own timeline, linked back to wherever it needs to show up.

This is the same trick used to handle[ public and private goals within what feels like one plan](https://guides.tability.io/docs/become-a-tability-power-user/how-tos/creating-a-plan-with-public-and-private-goals): create a separate plan for the goal that runs on a different cadence, then link it into the plan where people expect to see it. Users still have one place to check in on their own goals regardless of which plan holds them — the separation is structural, not something they have to think about day to day.

### A quick way to decide

If you're stuck on where a goal belongs, ask:

1. Who would discuss this goal in a meeting? That group's plan is where it belongs.
2. Does this run on the same timeline as everything else in that plan? If not, it needs its own plan, linked in.
3. Am I merging this into a bigger plan just to avoid a silo? Link it instead of merging it.
4. Is this plan still something one team would recognize as "theirs"? If a plan has stopped feeling ownable by any single group, it's grown too large.

<br>