How do we decide what's important to work on? Essentially the planning aspect. So from what I've noticed, we had been doing the 'planning' piece decently well, with OKRs in the past year, until I got involved. There would be some thought and direction from the Founders and that would get distilled down to everyone else. They would do the planning there, and some level of 'planning for the planning' beforehand. That's a big piece missing from our company process, at least from what it could be. In the past it would just be an email outlining what to do, which I don't think is enough. There wouldn't be full clarity and potential realizing activities. I don't blame them. They just don't necessarily have the systems thinking mindset that I have learned now. So there can definitely be more 'planning for the planning.'
So the purpose of planning is to get alignment on the vision and how we're going to achieve that vision. One thing missing in our process is a look back quantitatively at the past quarter. On both levels - results KPIs and process KPIs. Results KPIs like MAUs, revenue, churn, AOV, subscription customers, etc. And process KPIs like burndown of milestones, projected vs actual timelines, bandwidth taken by day-to-day activities, projected vs actual tasks / milestones complete, etc. Side note - I think due dates should become timelines instead of singular deadline dates. That way we can also view it on a timeline to see how it affects other tasks. We've been doing retros and we may have action items from it, but how well those action items are implemented is always hit or miss. There are no mechanisms in place to hold people accountable to process improvements as of now. That's why we keep getting the same results: delay on project after project, overpromising and underdelivering, underestimating how long work will take, how much time we can actually allot to moving things forward.
So the first thing we need to do is have a data-driven approach. Slight detour but I think in the process of unlearning, learning, and relearning, we do a bad job of unlearning holistically. We have these new things we want to implement but every time we add something, it feels like more and more and more. That's why there's a negative connotation to adding stuff to our system. Because that means more work and comprehension and different action. But in that process we don't intentionally ask what we're going to unlearn. We're trying to pile on a habit like working out while still eating unhealthy and expecting there to be results. Then we try some diet pills. Then surgery. All while that habit of eating unhealthy is still there, not being unlearned. So the unlearning is perhaps more important to progress as is implementation of the new habit. Learning is asking 'what does success look like?' Unlearning is asking 'what does success not look like?' For every new habit and practice we want to bring in, we need to kick some habit or practice out, so that it balances out. Or have the equivalent of what we're doing now with that habit and practice and show how we'll be replacing it.
What results have we gotten? How do we feel about those results? What results have we gotten about the process? How do we feel about that process? Results KPIs; 2U & LL retros; Process KPIs; OKR / OS retro. When we create an action item from these retros, we need to ask the additional question of what thing are we removing or making an adjustment to? For the quantitative piece, we need things that can have some sort of projected value at the end of the time period for which we're planning. Like timeline, milestones, revenue, etc. So we can ask ourselves where we hope to be at the end, so a projected vs actual.
So wrote this Saturday morning and now it's Saturday afternoon. I simply asked the question of what should the mechanism be. I continued listening to Robin Sharma's audio program and I found the answer. It's like life is almost too simple. Quite simple answer for the mechanism actually. If individuals want to track a habit, we use some sort of habit tracker every day or every instance we did or didn't do the habit. Same principle applies for the business. Whatever action item(s) we decide to focus on, we just make that the habit / practice. The habit tracker is then part of the Process KPIs; something we review on a weekly / biweekly basis. We just don't follow up on the action items, so even if we do them or don't do them, we don't know if it was intentional or how we performed, if it was effective, etc.
So what are these other Process KPIs? I figure the Results KPIs the leadership team will come up with. Well they're basically the equivalent of my daily quotients that I track. Sleep, diet, output, focus, energy, balance, TLDR, day speed, alignment, misalignment, and overall. For work, what are they? I think focus is one of them. The ability to do something for as long as you said you would without distraction. Something with communication. It can encompass many things but it has to be captured. I can include many of the characteristics from the radar chart exercise that we did in July. Alignment, Focus, Communication, Administration, Organization, Morale, Collaboration, Creativity, Wisdom. We can adjust these as necessary going forward but this is a solid list to start out with. However, we need to define each of these terms. I have a separate question for that so I'll tackle that then. So these characteristics can be tracked every sprint planning (every 2 weeks) along with the habit tracker. Whether the habit tracker is something that everyone updates or is updated generally and on what cadence will be determined by what that actual habit is.
So those are more quantitative process KPIs. What about qualitative KPIs? Having templates that has everyone's names already included on it reduces the friction and increases accountability. Something like Accomplishments, Disappointments, Improvements / Learnings for each person or at least each function. Ideally that's completed before sprint planning so we don't have to take time to do that within each meeting. So when we're reviewing these agreed upon KPIs every other week, it'll reinforce what are the important things. Not only the results, but the process to get us there. So all this work would be completed and all ready to go by the quarterly planning sessions because it'll have been getting done throughout. No need to cram any data aggregation. So in the retro piece, we can do the normal retro and the quantitative look back. Well actually, we may not even need to do a full retro because we will have been filling it out throughout the quarter.
OH! So what about this. We have the template already include the retro sections that we're going to review during quarterly planning. Throughout the quarter people fill in the items for whatever section of retro that's relevant. If there's anything that's not able to be captured by the retro, then there can be a catch-all 'other notes' section that people can fill in. This retro doesn't need to be reviewed every sprint planning. Only at the end of the quarter. And perhaps in the middle of the quarter. If someone wants to bring up something at any other priori point, then they have the ability to do so. So that's the first piece of planning. Now the meatier chunk.
We first got aligned on our vision in the Q4 planning session. This was 5 year vision, with a bit closer look until the end of 2022. We don't need to visit the 5 year vision every quarter but every year we should revisit it and update as needed. However, I do think we need to have some level of roadmap for the subsequent 12-18 months. So it doesn't need to be visited every quarter if it's done enough in advance but every couple quarters we should be looking at it. What should that 12-18 month roadmap include?
Stores opening
2U markets potentially launching
New hires
LL Live conference
LL 101 training weeks
We need to also look at the model for what the projection for stores, franchisees, and licenses is going to be.
Do any additional events need to be added? How will these events impact our OKRs? They'd naturally get trickled down into the KRs since they're large enough. But at the end of the KRs finalization, we should revisit if they were accounted for. So after creating that vision, then it's that alignment. Check the objectives. Check the objectives. Create the KRs. Objectives being the what; KRs being the how. Using the measurable aspect of it.
Then the KR owner, Functional team, Why, complexity and 100% targets for each of them. The priority we had in Q4 within the context of the sub-objective - is it valuable? Does anyone make or change a decision based off that number? For those KR owners, I don't think so, at least I haven't done so myself. I could see it being valuable if someone had extra bandwidth and then had to decide where to provide assistance. But even then, it's limited because people can only help so much across functions because of limited knowledge and expertise. I say we nix it but we'll see what others say. After doing that process on both 2U & LL sides, we then should take a look at the pivot tables. They help answer if someone is taking on too much workload (or too little) with KRs and complexity. Having these consistent metrics QoQ gives us insight into how our planning process has improved.
Ahh. Actually what we need to add to the Process KPIs is how much we committed to and how much we accomplished. 2 outstanding things are day to day and definitions of milestones so it's consistent. What about the relation between complexity score and milestones? 1-10 complexity. Another thing is how much task / milestone addition do we have to account for? 1-3 complexity KRs should have 2x the number of milestones, so 2-6 milestones. 4-6 having 8-12 milestones makes sense. 7-10 complexity KRs having 14-20 milestones is ok because it's complex. Lots of time / $ / effort being put into it.
So let's say 4 milestones in a 2 complexity KR. Completing 1/4 of those is the same as completing 4/16 in a 8-10 complexity KR? Yes, I guess so...? This is as close as you're going to get with getting unnecessarily scientific. Well, idk. It's either that or all KRs having a limit of X amount of milestones so that one KR is not being tracked so granularly compared to another. I'll propose both to folks and see what they say.
There's actually an Asana burndown chart that shows total number of tasks / milestones by date. So we can see how many were there at the beginning of the quarter and how many are there at the end. That way we can budget in that amount of time allocated to the unknown. Also, milestones should be things that don't really change throughout the quarter. The tasks / subtasks to complete the milestones may emerge / update as the quarter goes on but rarely should the actual milestone change.
Last thing here is the day to day. I think we just do what I do to capture it all which is have the equivalent of a separate KR to capture everything else. This can be a day to day / admin / planning / miscellaneous KR that's a catch-all for everything else. The point of this is to decide if someone has too much work assigned to them from a KR standpoint that they wouldn't be able to accomplish them while also doing the day to day. Since that's a dependency / limitation for how many KRs they can take on, this step needs to be completed first. The OKR rule is 5 for number of KRs. But should we revisit that to see what that number should be for us? Like how much of the KRs are we accomplishing every quarter? And how does complexity affect that progress?
We don't have consistent KPIs QoQ that can provide that insight. So that's one of the first steps. Maybe it's not 5 KRs discretely as the limit. Maybe it's KR x Complexity. So let's say someone has 2 KRs each with 9 complexity = 18 KR score. That's the same as someone with 3 KRs rated at 8,7,3 complexity. So then we have a limited number of KR points per person per quarter. Let's say it's an arbitrary 25. For someone like Tripp, his day to day /admin KR points would have totaled 22 or something. Leaving him only room for 1 KR with a complexity score of 3. Meanwhile for someone like me, it would have essentially been reversed with day to day KR score of 2 or 3. Leaving 22-23 KR points for other KRs. So the KR complexity totaled up would give the KR points committed to for the quarter. Then we can see this quarter how many KR points we completed. That's based on the milestones within each quarter. So if KR complexity is 8, it could have anywhere from 8-16 milestones. Let's say it was 12 milestones planned out. We completed 8 out of the 12 milestones so 8/12 * 8 = 64/12 = 5.33 KR points we completed. Repeating that for every KR, we get a total KR points finished. Then that could be one of the things we adjust our planning based on for how much we commit vs how much we actually accomplish.
Do we need something like that on the sprint level? Not if we have an aligned definition of milestones actually. Let's say it's uniform with 5-10 milestones / KR. Then each milestone is worth 10% of progress or more. So what about the milestones that can't get completed in a sprint? How do we track that? Are we okay with having milestones sit in In Progress / Blocked sprint over sprint? If so, then that's ok.
I think I've digressed from the main question I was trying to answer originally with planning. This is the implementation and a 'throughout quarter' question, which I'll save for another time.
So then after the KRs are complete, we take a look at the pivot tables, make any adjustments to owners and then lock them in. Then people individually go to the milestone boards and fill them out with whatever guidelines we establish. After that week has passed, then we have the sprint planning by pulling things in as we normally have.
That would conclude the quarterly planning phase and kick off the quarterly execution phase. When formalizing this, I need to create a template and timeline that has all these steps so it's laid out clearly and simply.
One dependency of the quarterly planning phase is the founders' vision and the model. And as we scale and grow we'll have to figure out which levels of the company do what so it can distill down all the way.
Comentarios