[Wikimedia-l] [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure

Thu Nov 8 04:53:32 UTC 2012

Picking up this thread as Erik asked me to explain the different functions
that fall under "Product".  To do that, it's worth describing in a bit more
detail how our project teams work.

This may be a bit reductive (apologies in advance), but there are a basic
set of things that need to happen when building a product.  These things
happen regardless of what the product actually is (e.g., t-shirts count):

1.  Decide what to build
2.  Design it
3.  Build it
4.  Measure how it's used (if you want to improve the product)

Roughly speaking, that's how we organize our teams when it comes to
building features.  Product Managers decide what features to build,
Designers design the feature, Developers build the feature, and Analysts
measure how the features perform.  (features = things on our websites or
mobile that readers or editors would use).

Let's take PageCuration as an example of a feature that WMF developed.  In
this case, the feature development team consisted of a Product Manager,
Designers, Developers, and Analysts, all working together.  Here's how the
various roles worked:

1.  Product Manager [1]:  Represents the user's point of view.  Works with
the rest of the team to identify and solve a user problem.  For example, we
knew that the backlog for Special:NewPages on the English Wikipedia was
consistently too large and that existing page patrollers felt overworked.
To solve the problem, we needed to make page patrolling more efficient
[2].  Product Manager worked with the rest of the team to develop potential
solutions to this problem.  The outcome of this was the decision to build
two separate features for the end user (i.e., page patrollers):
Special:NewPagesFeed [3] (redesign of Special:NewPages) and the Curation
Toolbar.

The Product Manager worked with the rest of the WMF and volunteers in the
community to identify specific features by asking question such as "If we
were to redesign Special:NewPages, what kind of information would page
patrollers want to see that would make their jobs more efficient.  Out of
this inquiry came ideas like surfacing the # of categories, # of citations,
whether an article is an orphan, a snippet of the content, etc. as these
pieces of information would help the patroller determine which articles
warranted attention.  Fabrice Florin was the Product Manager.

We also have a Community Liaison (Oliver Keyes) who is responsible for
reaching out to the editor community to make sure the feature we're
building actually meets the needs of our editors.  The Community Liaison
creates the space where community members can give input into the feature
by holding IRC chats, on-wiki discussions, reaching out to editors, etc.

2.  Designer:  The designer then takes this input and designs the user
interface for Special:NewPagesFeed.  Part of this is Interaction Design [4]
e.g., how are the elements of the page laid out so that page patrollers can
easily parse the information?   How does a page patroller actually
accomplish the task of selecting an article to review (e.g., should there
be a "Review" button associated with each article, or should the article
link be sufficient?).  Does this action open up a separate tab?  How should
filtering of this list work? Etc.

There's also Visual Design:  How do we use color to help identify the
different states of an article?  How can icons be used to reduce the
cognitive load associated with parsing information?  How can we create a
look & feel that's visually engaging?

Brandon Harris and Vibha Bamba were the designers for Page Curation.

3.  Developer: The developers then take these functional and design ideas
and code the feature.  On this project, the developers were Ryan Kaldari
and Benny Situ.

4.  Analyst: The data analyst works with the developers to determine what
types of stats would give the team a handle on whether/how the feature is
being used.  For example, here is the dashboard that Dario Taraborelli:
http://toolserver.org/~dartar/pc/

These roles aren't rigidly defined.  For example, ideas for features can
come from anywhere, not just the Product Manager.  In my view, a
well-functioning team is one where everyone is engaged in coming up with
ideas.  But there should be someone responsible for ensuring that the
various ideas come together into a coherent whole, ones that addresses the
problem at hand.  That responsibility lies with the Product Manager.

Also, Product Managers and Designers don't spec out stuff which they then
hand over to developers to build.  Teams work collaboratively to come up
with solutions.

That's how our project teams are structured.  When it comes to the proposed
organizational structure, "Product" consists of Product Managers,
Designers, and Analysts (1, 2 and 4) and "Engineering" consists engineers
across the different areas Terry describes.  One way to view it is that
"Product" involves everything outside of writing code for a feature and
developers in "Engineering" write the code.  It's oversimplification (e.g.,
analysts write code for analytics work, designers may prototype), but I
think it's directionally useful.

The individuals in Product and Engineering are then matrixed into project
teams like the one described above for Page Curation so project team
structure != organizational structure.

Howie

[1] http://www.quora.com/How-can-I-learn-to-be-a-good-Product-Manager
[2] This is a slight oversimplification
[3] https://en.wikipedia.org/wiki/Special:NewPagesFeed
[4] http://en.wikipedia.org/wiki/Interaction_design

On Wed, Nov 7, 2012 at 2:49 PM, Erik Moeller <erik at wikimedia.org> wrote:

> On Wed, Nov 7, 2012 at 2:16 PM, Platonides <Platonides at gmail.com> wrote:
>
> > You can see several teams in that page, with members from multiple
> > "sections". Which leads to the (naive?) question on what's the purpose
> > of being splitted in those sections if then the work is done in teams
> > with a completely different organization.
>
> The purpose of functional groupings is to ensure that there is
> coordination and communication among people who share a function (e.g.
> all designers), and that they have management support, ideally from
> someone who understands their function and purpose in the
> organization, and is able to help them grow in their career and as an
> individual contributor. It creates escalation points in case of
> conflicts, and can help to remove blockers.
>
> The purpose of team groupings is to ensure that a team is assembled
> cross-functionally, from all the required skills, and fully focused on
> delivering its objectives.
>
> The two organizational models are complementary; the singular focus on
> one or the other tends to lead to silos. Achieving a healthy balance
> between intra-functional team development and growth and
> cross-functional delivery is one of the key challenges of management.
>
> Erik
>
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
>