Wikimedia Discovery/Meetings/Interactive team health check 2016-12-14

This month, the Interactive team participated in a health check survey. This page summarizes how the team feels about itself, within each of the focus areas.

FOCUS AREAS

Mission and Goals:

• The team knows why they are here, but feels lacking in long-term direction and stability.
• The mission is not unclear, not uninspiring, but could definitely be clearer and more inspiring.
• There are goals, but they are a bit imprecise, as are the KPIs.
• Shorter term stuff is less clear but the end-goal is.

Value:

• The team feels people value the work it is doing.
• The resulting product is hard to use for non-technical people, and the learning curve is high.
• Experiencing problems delivering the product to everyone (deployed to way fewer wikis than hoped).
• Lots of good comments, but it's hard to get rid of the existing Geohack in templates.
• Uncertain whether the KPIs determine the actual value in regard to Quarterly Reviews and management, which is what they should be doing, otherwise they are the wrong KPIs.

Community Involvement:

• Sometimes there are no responses from the community, and it's sometimes difficult to know whether people value the work.
• It's unclear whether the small amount of feedback received is good enough.
• Don't know whether to target content, functionality, reading community, editing community, or try to target them all; it's a bit unclear.

Delivery:

• Pushing code to production itself is very smooth.
• There are complaints about the build process around node.
• Lower-level stuff is not as good/easy as it should be, nor is it as safe as it should be.
• Could be better at testing/quality metrics:
  • There are quite a bit of unit tests, Kartographer back end gets tested well, integration/backend maps testing could improve;
  • There are health checks for maps servers, but it's not a streamlined process.
• It's simple and painless, but we seem to make it less simple by trying to make it "safer," and it feels like it is taking more time than it should in the end.
• No complaints have been received from release engineering which, for the most part, keeps track.
• There’s a little confusion over versioning; the train adds versions each time, but not on the kartotherian/tiles side of things and each version has a lot of packaging.

Quality:

• It doesn't seem technical debt ever gets paid down.
• Things that keep the team from addressing technical debt:
  • There is not a good balance between new feature development and keeping things polished (code quality, addressing bugs, and user feature requests).
  • There are things that live in the interface between dev and ops that could be addressed, but there’s often not enough time.
  • For those who work on multiple teams, managing priorities between them is a challenge.
  • Tech debt does not increase so much on the front-end, although it still does, and mostly results in the lack of testing and audits, in favor of developing more valuable stuff for users. Limited resources do not allow much time to focus on improving the quality of existing code.
• In general the team feels it is not good on prioritization; there are tasks that have been stuck.

Communication:

• If we can't get trust, diplomacy would be a good target.
• It’s hard to keep track of what's happening and know what was decided or not.
• Not all communication is clear or repeated.
• Being more proactive about sharing what's actually being worked on would make things go smoother.
• Most of the communication happens on IRC, which is active but messy, and mainly engineers hang out there. A lot of things happen there and it's easy to miss stuff.

Pace:

• Either everything is fine, or it's rushed or stuck.
• In conversation, everything is urgent, and that's difficult to deal with that breakneck pace all the time; things break, things get more difficult.
• Pace is often so quick that community is back-burnered.
• Not spending enough time to understand what the missing steps are.
• The normal process is to discuss a topic and vote as a team, and every team member has veto power.
• When the code is done, it doesn't mean it's ready to push into production.
• While engineering might be complete, the community outreach portion may not have been started and/or might need more time.
• What one person sees as trying to help, another may feel like it slows things down.
• There never seems to be planning meetings about what needs to be done by each role.
• Overall, the pace is good, but focus is lost in doing way too many things at the same time and it’s easy to miss things.
• There is a lot of context switching, which drags the team down and makes things complicated. It would be better to focus on fewer things, maybe there's too much work for the size of this team.
• The team should have one main goal per quarter, with a sub-goal for improvements.

Learning:

• General feeling is team members don’t have time for learning new things, even given the 10% time allotment, which it seems nobody gets to take advantage of. 10% time is used to work on Interactive team side work that really should be getting done during the other 90%, and so the 10% doesn’t get used for learning or other purposes.
• There is learning that happens on the project, but not necessarily learning that people are highly interested in, but is rather part of the job (ie. debian packaging).

Safety:

• Some feel safe enough to speak their minds, others don't and feel they need to be more guarded.
• When something gets reacted to in IRC with scolding, it erodes trust on the team.
• There are a lot of problems that can be solved directly between two people; if issues get escalated before that chance has happened, it erodes trust.
• Misunderstandings on IRC should immediately be addressed with the person who wrote it, rather than being escalated to larger groups before having that chance.
• Direct communication should be the first approach. It's professional and far more effective than running up the chain to get something done.
• Emails to the whole team should not be viewed as “making a big deal” out of something, but rather as an attempt to rope others into the conversation. Not everyone participates on IRC or makes it to all the meetings, but email is something we all use. If someone sends an email, assume good faith and take it in stride. Don’t look for deeper motives than that.
• Sometimes it is not clear how to approach other people with concerns.

Support:

• Got better UI Standardization support, as well as support from other designers. Nice trend.
• Team feels more and more distant from the rest of Discovery, and from being part of one department.
• Help from analytics has been minimal.
• If the team needs something, members go and get it from other teams/individuals.
• In Search, there is a lot of overlap with Reading, and the interactive team could benefit from building those same overlaps; we're talking collaboration more than support.

Fun:

• Tensions in the team make it challenging when it comes to knowing when to be serious and when to crack a joke

Innovation:

• According to the community, the team seems to be very innovative.
• The team is pushing into new territory with editable content that isn't text (90% of what's in our projects). There is an eagerness to see the adoption of these tools change the way folks interact with the knowledge volunteers create.

Destiny:

• Team feels it gets to decide how to organize and get our work done, but also that they can do it better.
• The team feels it is heading toward the same goal, but not as a team.

Action items:

• Things requiring clarification:
  • Clarify team mission.
  • Clarify value targets and identify meaningful KPIs that demonstrate the value the team is delivering to those targets.
  • Clarify community feedback expectations--how much is good enough?
  • Clarify who Interactive is targeting in terms of community: content, functionality, reading, editing, or all of them?
  • Clarify what management really expects.
  • Clarify what is considered a release.

• Things that could use planning:
  • Come up with a plan to make it easier for non-technical people to create maps.
  • Determine what can be done to improve quality and raise the level of safety when deploying, including testing and quality metrics, improving integration/backend maps testing, and creating a streamlined process for map server health checks.

• Other action items:
  • Identify and address complaints about the build process around node.
  • Further improve Phabricator board organization and prioritization of tasks.