Meeting Notes/2016-02-22 Core Fraction C-level check-in

Present: Joel, Kevin, Wes, Jaime, Kristen, David Strine, Lila

Brief on implementation to date

(experiment last year, pilot efforts, Annual Planning prep). Jaime: How have you seen this working out?

Wes: This initiative has been pushed by management for a while. The group of people in this room seems like the right group to make decisions.

Jaime: Important to have a process. Not just activities. In a budgetary point of view, since the definition was not available at the start, there was a broad range of interpretation. So it was neither fully useful, nor useless. Interested in better understanding the purpose of this initiative, and then be able to use it to benefit all stakeholders (including those who are putting together plans). Needs to be useful. Context helps people engage.

Wes: Want to have a good sense of where everyone is standing so we can move forward.

Joel: Teams track their work in Phabricator. Joel has been working with VE, asked them if they want help tracking interrupt work. Terry (former COO) joined the Foundation and had some ideas about the tracking categories and usage...

Jaime: What is the purpose?

Joel:

1. Team-level planning,
2. Budget/Quarterly/Annual planning (capacity - “once we do the maintenance, what’s left over?”)
3. external (IRS, charity, etc) (note: don’t want to muddy the waters of 2 with IRS definitions - separate use cases).

We piloted some related attempts in the Fall, reception of the effort and tracking “buckets” varied. Teams are concerned with what this type of information will be used for- this is a huge barriers. “CompStat effect” to make numbers fit institutional incentives and unconscious bias are both potential issues that would cause teams to report inaccurate numbers.

Wes: So far, almost all the work has been with engineering teams.

DStrine: Current terms are “Core” and “Strategic” - do you have an idea how this will be used, and what your interests are?

Jaime: Engineering has the highest level of complexity. Needs to understand what it is producing for itself, for the rest of the foundation, and for external. Non-engineering teams seem more straightforward--what they do fall into clearer categories.

Coming back to the conclusions: We have experimented. I’m a practical person. Based on everything done so far, we can think “how can we purpose our learnings?” rather than create another abstraction. My context is grounded in other similar concepts, but my preference is to start with the input from the learnings. Repurposing the definition right now probably doesn’t make sense, since we’re already doing planning for this year.

Joel: Individual teams have a need: We are doing X and Y, but we are asked to do Z. We could, but that might add ongoing maintenance of Z, which will reduce future capacity. In theory, it would be helpful to know how expensive ongoing maintenance of Z would be. But that is a couple years out, and is probably at the limits of what we could expect to generate. Probably not what Lila and Terry had in mind. What does seem more relevant and applicable is stuff like: If a team was at 20% maintenance last quarter, and 40% this quarter, who would look at this data, and what would they do with it?

Wes: Original purpose was to help with annual planning. Help identify where we’re currently putting our effort and resources. Also try to carry forward things around prioritization of new work.

Lila: Primary reason is to understand how much we spend and what results we get in core -- we assume maintain only. the difference is: the work moving the needle i.e. more editors, more reader etc.

Joel: The definitions in engineering are so slippery. For example, if VE adds Korean...is adding that core or strategic? What if it overlaps with Japanese? Is Japanese Core or strategic? A year later, is bug-fixing [last year’s Strategic initiative] part of core? Teams have no trouble coming up with examples that could go either way.

Jaime: That criteria (of putting it in a bucket to get more or less money) is not sensible. The work should stand on its own merit to decide whether it deserves more money or not. We need to be careful; people are trying to impose criteria. We need to return to the practical: How can we use this information to benefit everyone? After we have that, then take it up a [conceptual] level to see how we might use it.

Joel: Example from ops: We could use this new tech to reduce the number of servers to be more efficient. Is that work core or strategic?

Jaime: What is *their* definition? We need to be able to identify goals, milestones, and resources required to get there.

Joel: Seems like we can do that without core/strategic.

Jaime: We have done a strategic consultation, which has defined strategic. That makes it more useful than the maintenance conversation.

Joel: So if it aligns with strategies, it is strategic work. Anything else is core?

Jaime: The answer was in relation to the strategy. It has already been documented through the consultation.

Jaime is working with individual teams [as they submit Core annual plans] to clarify how they have done their categorization. Teams have self-labeled “core”, but in some cases C-levels might feel some work is really strategic, so it would be moved. We haven’t gotten strategic budgets yet, but hopefully plans will align against those objectives.

Joel: TPG was asked to clarify the core/strategic terms. I think we’re hearing that dividing work into those buckets only needs to happen in the annual plan budget proposals. Do we need to help anyone else else?

Jaime: Curious to hear from others here. Overload isn’t helpful.

Wes: I wanted to get these definitions clear and public. TPG has been splendid trying to work through that process. Taking it to the next level, the expectation always was to work with TPG to try to define whether or not it is useful.

Jaime: To paraphrase: It was a project to help better define these terms. To help both the people doing the work and categorization, and the people viewing it (e.g. execs).

Future plans

Joel: The next concrete step we have been planning was for teams to actually track their work throughout the year, within these buckets, to see how reality aligned with the original budget. However, this will have overhead and costs to have teams do this day-to-day. Would that have value?

Jaime: Yes. Going back to root causes, such as working on non-priority projects. Teams have already self-reported in these categories. We can help evolve the definitions to be more practical and useful. This is a process, not a project.

Kevin: Are we going to ask teams to track these buckets moving forward?

Jaime: Do we need to answer that now?

Joel: Yes, because there will be months of ramp-up to develop processes and train teams.

Kristen: TPG has a Quarterly goal to pilot tracking. We want to understand whether or not to proceed with that. I agree with Wes that we have framed this as “will this be useful?” Some of the pressure here may be TPG wanting to know about the goal, and then for other teams to gain clarity.

Jaime: From the root problems, yes, tracking seems necessary. Some teams themselves want it. And for accuracy of planning, including capacity planning, we need it. It would also help for external reporting transparency. But how do we make it practical? TPG has a better idea of how it can work. I did expect it to take months. Based on what we know, what could be the next steps? Evidence-based planning is important. I’m listening to the evidence you are presenting.

Joel: We’re out of time. I may have overstated team interest in this. Some teams said “no thank you” unless there is some important reasons -- they didn't get anything out of the data and so it was just added work with no benefit. For other teams, it’s relatively easy to generate. A few want the information. Teams are generally happy to do the work, as long as the benefits are clear. TPG has struggled understanding what it’s for.

Jaime: It’s for the roadmap. I hope we agree there’s a clear purpose why we’re having this conversation.

Joel: The details are so fuzzy that teams are really struggling with the buckets. There are a lot of examples of work that could go into either area. That’s a major reason that we keep getting stuck with this.

Wes: I appreciate your patience with this. I’m mostly concerned with unduly burdening teams with tracking this. I’m still just getting through this annual process. I can help write up a retrospective.

Lila: I agree with Wes. Thanks to the team for working through this, and trying to find the best balance between accuracy and simplicity. I think we should get through the annual plan first, and then work more on this. We need to be able to divide the way we currently do things against doing future things that could have more impact. From a business lens, this would be to keep doing, vs. to increase impact. Separating the programmatic things should help, moving forward. The hardest part is taking this through the whole organization and making sure everyone understands it.

Joel: Our next step is to continue the pilot for now, with the teams that are doing it.

Wes: It’s OK to take this slow. Much more important to have a clear result at the end. Working with existing teams will help us learn what is useful. Retrospectives are usually helpful. I’m mostly concerned with having something useful that teams can use to prioritize and plan.

Jaime: Would TPG continue to be involved with teams tracking this in the future?

Joel: Probably, yes. We are already embedded in some teams, so this would be part of that work.

Wes: TPG is very valuable with team engagement, coaching. Hard to quantify, but the impact of each TPGer on specific processes in my time here so far has been immense. Even if hard to quantify.

Jaime: We are striving for better definitions.