The Shared OKRs/Projects feature in Ally is a great way for multiple teams & owners to collaborate on their key priorities and initiatives with equal ownership.
When to create shared OKRs/Projects with Multiple Teams/Owners?
When an OKR is a key priority for 2 or more functional teams and the team leads need to have shared accountability as the exact contribution cannot be proportioned or separately broken down between them. When both the teams are supposed to commonly own and work towards the outcomes, it is good to tag multiple stakeholders and not just a single team/owner as accountable.
Example 1:
OBJECTIVE: Enhance the onboarding strategy.
KEY RESULT: Implement a new program to increase the repeat rate of 1st-time bookers.
[Entity: Team(s) - CRM Team & Marketing Team]
[Owners: CRM Lead & Marketing Lead]
Example 2:
OBJECTIVE: Build a world class Engineering org.
KR/INITIATIVE: Invest in 2 Training & Development sessions + Capstone Projects for all 4 engg. teams this quarter
[Entity: Engineering Department]
[Owner: VP-Engineering & All Engineering Managers]
Example 3:
OKR: Facilitate seamless Annual & Quarterly Goal planning across the org.
[Entity: Org level]
[Owners: CEO & VP - Strategy & Operations]
In the above examples, if not for Ally's flexible shared OKR model, it gets cumbersome to create duplicate and redundant OKRs for every team/individual when they are supposed to be commonly owned, worded & measured
What are the different types of Shared OKRs possible in Ally?
OKRs at an Org entity level - can have Multiple Owners
OKRs at Team entity level - can have Multiple Teams tagged & respective Team odmins/members tagged as owners
OKRs at Individual entity level - can have Multiple users assigned as Owners
Note: A DRI (Directly Responsible Individual) is accountable for ensuring that OKRs are being properly defined, measured and accomplished. Multiple owner assignments can hamper accountability and encourage lack of discipline. Please review if it is absolutely essential for your OKR process before adopting it.
When NOT to create shared OKRs?
For Org/Team/Individual level OKRs, where there is clarity on the exact Key Result metrics or projects to be owned by respective teams & owners, do not create a single OKR and share it among all, instead create an Objective at the required entity level and create respective single team level Key Results owned by a single DRI so it is deconflicted.
Example:
OBJECTIVE: Skyrocket revenue in 2021!
[Entity: Org level]
[Owner: CEO]
KR1: Double the ARR every quarter.
[Entity: Sales]
[Owner: VP-Sales]
KR2: Maintain a 120% Net Revenue Retention Rate.
[Entity: Customer Success]
[Owner: VP-CS]
For cross-functional teams where all different stakeholders are part of respective mission teams, the Objective can be owned by a single team with KRs being worked upon by respective function related DRIs within the team.
Example:
OBJECTIVE: Provide best-in-class integration experience for customers.
[Entity: Team - Integrations & Partnerships Mission team]
[Owner: Mission Team Owner]
KR1: Go above & beyond on 5 Enterprise & 5 SMB platform integrations.
[Team: Integrations & Partnerships Mission team]
[Owner: Product lead]
KR2: Enhance the Integration sync time performance by 3x.
[Team: Integrations & Partnerships Mission team]
[Owner: Engineering lead]
KR3: Partner with the top 3 industry leading HRIS providers.
[Team: Integrations & Partnerships Mission team]
[Owner: Marketing/Partnership lead]
Enabling the Shared OKRs feature for your organization
OKR Admins can turn on the shared OKRs feature from the 'OKR and Projects' section within the admin settings.
In case you disable the feature, multiple teams and owners who have previously been assigned to OKRs will continue to exist. Once disabled, users can only add single owners to OKRs and Projects
How to create shared OKRs for multiple teams?
Log in to Ally.io and click on the ‘+’ button on the top panel to create a new OKR
Once you enter the objective/ Key Result and want to share it with another team, choose ‘Team’ from the drop-down under ‘ Type’
You can either scroll down for your team of choice or search for the respective team in the search bar
Once you select the team and save the Objective/ Key Result, you will start sharing the OKR with that team
Users can also assign multiple teams to Projects in a similar way
How to create shared OKRs with multiple users as owners?
Log in to Ally.io and click on the ‘+’ button on the top panel to create a new OKR
Once you enter the objective/ Key Result and want to share it with another individual, choose owners from the ‘Owner’ option. Here you can assign multiple owners for the OKR
Once you select the owner and save the Objective/ Key Result, you will start sharing the OKR with that individual
The user who has been assigned as the owner will also receive an in-app notification notifying the same
Check-ins for single and multiple owners
If there is just one owner or multiple owners assigned to an OKR and you would want a user within the organization to check-in and update the progress of the OKR, you can use the ‘check-in responsibility’ feature. The check-in owner will be able to check-in on the OKR (manual check-in) as well as set-up a data link on the OKR (to auto-check-in). This user will be receiving the check-in reminders. In the case of multiple owners, this will prevent all of the owners from receiving reminders, only the user set as 'check-in responsible owner' will receive the reminders.
Steps to assign responsibility for check-ins:
Log in to Ally.io and click on the ‘+’ button on the top panel to create a new OKR
Once you enter the objective/ Key Result and want to share it with another individual, choose owners from the ‘Owner’ option. Here you can assign multiple owners for the OKR
Once you assign an owner, select the user who will be responsible for making check-ins from the ‘Who is responsible for making check-ins?’ drop-down
Once you make the selection, the user will start receiving the check-in reminders
By default, the owner (the first owner in the case of multiple owners) is set as the person responsible for check-in and users need not explicitly choose unless necessary