WMF product development process/Current

Task tracking and planning

Engineering teams have processes (mostly Scrum/Kanban), and they work at the micro level. But at the level of foundation-wide processes and resource decisions, the processes don't align well. Teams set their own backlogs, filtered by product people. The range of inputs spans bottom-up (community tickets) to top-down (quarterly goals). Adding work to a backlog is the de facto way of assigning WMF resources to a task, so that’s a bottom-up, semi-organic process. For most teams, that goes through a Product Manager or team lead, synthesizing many inputs from many levels of hierarchy.

A team accepting work into the backlog is the bottom-up equivalence of WMF assigning the people on the team to tackle the work. But teams petition for permanent and temporary people, which is a top-down process. Neither process is perceived as consistent, accessible, or transparent.

Teams are juggling new work and maintenance.

Work assignment doesn’t align very well with resources

Goals

Team Goals are set at the manager level on a quarterly process.

Example: FY2015/2016 Q1 Goals process

Week Ending 6/7 - Lila’s Direct Report (level 1)
Week Ending 6/14 - Level 2
Week Ending 6/21 - Level 3 and Individual Contributors
Week Ending 6/28 - Staff Goals
Sep 29 to Oct 1: Presentation Clinics
October 5 through Oct 8: Quarterly Goal Review Meetings

Alignment of Goals

Those goal lists do not include all of the work that everybody is doing; i.e., they don't map precisely to Phabricator. they don't necessarily synchronize with the Foundation's goals overall, which in turn don't perfectly reflect the Movement's needs (and can't, since the Movement is too big and diverse to have a single, consistent set of requirements). As we get away from maintenance, it’s not clear we get to “what the community needs”. We’re good on the “lights on” stuff, and less accurate at broader scopes of work. Discussion: "We don’t know what the community’s priorities are." "We could optimize for different questions." "We need to build a consensus on what we’re trying to fix."

How important is it for the high-level goals to align with the bottom-up work? Terry: I would question whether tasks and goals connect in a tightly coupled way. Trevor: the goals that we set only represent a part of what we do.

Joel: We don’t have a process for teams to measure what X% isn’t covered in our accounting. Terry: We need to get goals that relate to OKRs. Goals and task tracking are typically separated rather than tightly coupled. Joel: Agreed that we shouldn't try to track 100% of everybody's time in Phabricator/goals/etc, but what how tight should it be? Do we want a warning when the amount of work a team is doing that doesn't track to any of their goals exceeds x%? A sign that either the goals or the work is off track? Trevor: Managers handle this by leaving room in the workload for engineers to have flexibility. Katie: I have a massive backlog of stuff I want to do to give us more visibility, but the pace moves quickly, we haven’t had the chance to make our own stuff nice for ourselves. We can’t just decide we just want a new payment method. Terry: I think you can overregulate. we have to build slack into the system. Scale the overhead to the decisions. Trevor: precision needs to be calibrated. You can get so obsessed with precision. Katie: I’ve seen arguments whether we should do X last longer than doing X.

Two models of how tightly goals should tie to daily work: Slack model - don’t book every minute. Prioritization framework: Tie goals at least in bulk. E.g., be able to report that 50% of work last quarter was on Goal 1, 20% on Goal 2, 10% didn't match to any goal, and 20% was explicitly overhead.

Output vs Outcome

Currently we don't differentiate clearly between output and outcome in setting goals and OKRs. Trevor: just look at our quarterly goals. Some teams tend to do more of one or the other.