I’m excited to share the first in a series of posts around how we do CS Ops at Gainsight! We’ll be starting with our OKR+Project+Sprint Planning processes as these are the backbone of how our team operates across our entire Ops & Scale organization. My hope is that this is helpful for any teams looking to begin a similar process or are looking for inspiration. If you missed the initial post, check out other topics we’ll be discussing an feel free to add additional ideas!
This is a process we’ve iterated on over the past 2.5 years and will continue to tweak as we go. I’d love to hear other ways your teams are planning your work.
If you prefer videos over reading, I put together a 12-minute recording (sorry, I got carried away 
).
At a very high-level, this is how our team thinks about the planning process and various inputs across the organization. This is the guiding principle for how we’ve structured the setup.
We leverage Monday.com for our planning and project tracking. It’s structured into three “boards” for tracking OKRs, Project/Programs, and 2-weeks sprint tasks.
The OKR board provides exec level visibility into the important strategic and OKR projects the team is undertaking. It can be organized by OPSP pillar, Planned Quarter, Status, and many other ways.
Projects are broken out into a series of “boards” that each individual team in Ops & Scale manages. For cross-team projects, the team that owns the individual projects will assign tasks to teammates. From here, we can assign sprint items for each project and update the corresponding sprints and timeline.
Lastly, the project tasks trickle down to the sprint board, where individual teammates track their progress and hours. Each sprint item is related to a project task, which allows us to understand the progress of the entire project as the team is working. As work is completed, the status is updated and the actual hours are aggregated up to the projects and OKRs.
We also start the quarter by thinking about the team’s overall capacity in terms of “cake slices”. This is a concept we borrowed from our product team. We look across all possible projects and try to align capacity against these general buckets. We want to avoid overcommitting on strategic or net-new projects as CSMs wouldn’t be able to keep up. We also can’t spend all of our time fixing data issues or making the rules engine pretty (though wouldn’t that be nice!). This is an idea of how we break this out for each quarter and typically the percentages will move around quarter over quarter.
Planning capacity is a little more tricky but generally we plan for 70-75% capacity for the quarter. Which accounts for meeting time throughout the week, professional development, company holidays and recharge days, and PTO. We look at capacity on a sprint by sprint basis and adjust as needed. This is a very rough draft of how that could look!
I’ve purposely avoided going into too much detail, as I want this to serve as an inspiration vs. a playbook on how to develop a process. If you’d like to learn more or go into the specifics to brainstorm on how you’re thinking about it, please reach out - I’d be happy to chat!
