Recommended structure for your workspace
During your trial or after, how to best set up your Tability workspace
Last updated
During your trial or after, how to best set up your Tability workspace
Last updated
Tability is designed to be flexible, but we do have some recommendations to simplify your workspace structure.
Contents:
Tability is built to be flexible and works with anything from a single small team, to complex organization structures. But how many people to include in Tability when you first start using it can be bigger question. We suggest a few different options:
Full org rollout: For smaller teams (under 20 people) where everyone owns some part of the quarterly goals, bringing everyone on Tability all at once can work well.
Leadership pilot: For larger organizations, and particularly those who are new to OKRs or other goal setting methodologies, starting with just the Leadership team for the first quarter can help define your processes, making a larger rollout smoother in the future.
T-shaped pilot: For very large orgs or orgs with complicated structures, having both the leadership team as well as a single function (departments, projects, squads, etc.) can help you understand not only how the process works, but what a larger reporting process will look like. Having an extra team on the platform during your first quarter pilot helps define best practices before you bring in the rest of the organization.
Check out this video for more details:
Some separate best practices:
Anyone who is responsible for reporting on goals should be added to Tability
Anyone who is working/collaborating on a goal should be added to Tability
Anyone who just wants a top-level overview of your OKRs does not need to be included in Tability. Tability generates read-only reports that can be sent to team members who don't have access to Tability directly.
Anyone who wants to deeply dig into the goal data should be added to Tability (CSOs, Chiefs of Staff, Head of Strategy) so they can explore all of the different plans and goals at once.
Don't put all your OKRs in a single plan. We recommend having one plan per team, per cyle.
For instance:
A plan named "Company OKRs 2023 Q4" should contain the top-level Q4 OKRs.
A plan named "Product OKRs 2023 Q4" will contain the OKRs of the Product team for Q4.
Limiting the scope of each plan to a specific department, team, or individual will increase focus and improve readability.
You will also find multiple views allowing you to look at the goals of multiple teams together if you need to.
It's likely that you'll have multiple teams needing multiple plans to track their goals. To make things easier, we recommend grouping your plans by cycles.
You'll notice that we keep the annual OKRs separate from the quarterly OKRs.
It will simplify navigation, and will make it easier to access quarterly plans in the Strategy Map.
Here's below a recommended structure for an org that has 1 set of annual OKRs, and 2 sets of quarterly OKRs across multiple teams.
📁 Company 2022 OKRs 📁 Company 2022 Q2 OKRs |-- 📁 Engineering 2022 Q2 OKRS |-- 📁 Marketing 2022 Q2 OKRS |-- 📁 Product 2022 Q2 OKRS 📁 Company 2022 Q3 OKRs |-- 📁 Engineering 2022 Q3 OKRS |-- 📁 Marketing 2022 Q3 OKRS |-- 📁 Product 2022 Q3 OKRS
To create sub plans, first create your first plan. Then, at the bottom of the plan dashboard, click Add sub-plan:
For OKRs to be effective, we recommend adopting a simple ritual that will create a natural accountability towards outcomes for the team.
Every Monday:
Start the week by looking a the progress on Key Results
See if you need to adjust your roadmap/plans
Every Friday:
Demo with the rest of the team to celebrate the good work that's been done towards your Key Results.
Your team should fill out their check-ins in Tability either at the end of the day on Friday (after sharing their work) or before your OKR review on Monday. This ensures that when you're discussing your OKR progress during your meeting, everyone's already added in all of the necessary context.
You set your check-in schedule when you created your Tability instance. If you'd like to change the day, you can do so from the Workflow section of your workspace settings:
